draft-ietf-rats-msg-wrap-04.txt   draft-ietf-rats-msg-wrap-06.txt 
Remote ATtestation ProcedureS H. Birkholz Remote ATtestation ProcedureS H. Birkholz
Internet-Draft Fraunhofer SIT Internet-Draft Fraunhofer SIT
Intended status: Standards Track N. Smith Intended status: Standards Track N. Smith
Expires: 30 August 2024 Intel Expires: 2 January 2025 Intel
T. Fossati T. Fossati
Linaro Linaro
H. Tschofenig H. Tschofenig
27 February 2024 1 July 2024
RATS Conceptual Messages Wrapper (CMW) RATS Conceptual Messages Wrapper (CMW)
draft-ietf-rats-msg-wrap-04 draft-ietf-rats-msg-wrap-06
Abstract Abstract
This document defines the RATS conceptual message wrapper (CMW) This document defines the RATS conceptual message wrapper (CMW)
format, a type of encapsulation format that can be used for any RATS format, a type of encapsulation format that can be used for any RATS
messages, such as Evidence, Attestation Results, Endorsements, and messages, such as Evidence, Attestation Results, Endorsements, and
Reference Values. Additionally, the document describes a collection Reference Values. Additionally, the document describes a collection
type that enables the aggregation of one or more CMWs into a single type that enables the aggregation of one or more CMWs into a single
message. message.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 30 August 2024. This Internet-Draft will expire on 2 January 2025.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 33 skipping to change at page 2, line 33
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Conceptual Message Wrapper Encodings . . . . . . . . . . . . 5 3. Conceptual Message Wrapper Encodings . . . . . . . . . . . . 5
3.1. CMW Record . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. CMW Record . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. CMW CBOR Tags . . . . . . . . . . . . . . . . . . . . . . 6 3.2. CMW CBOR Tags . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Use of Pre-existing CBOR Tags . . . . . . . . . . . . 6 3.2.1. Use of Pre-existing CBOR Tags . . . . . . . . . . . . 7
3.3. CMW Collections . . . . . . . . . . . . . . . . . . . . . 7 3.3. CMW Collections . . . . . . . . . . . . . . . . . . . . . 7
3.4. CMW Tunnel . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1. CMW Collections' role in composite Attester
3.4.1. CBOR-to-JSON . . . . . . . . . . . . . . . . . . . . 8 topology . . . . . . . . . . . . . . . . . . . . . . 8
3.4.2. JSON-to-CBOR . . . . . . . . . . . . . . . . . . . . 8 3.4. CMW Tunnel . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Decapsulation Algorithm . . . . . . . . . . . . . . . . . 8 3.4.1. CBOR-to-JSON . . . . . . . . . . . . . . . . . . . . 9
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4.2. JSON-to-CBOR . . . . . . . . . . . . . . . . . . . . 9
4.1. JSON Record . . . . . . . . . . . . . . . . . . . . . . . 9 3.5. Decapsulation Algorithm . . . . . . . . . . . . . . . . . 9
4.2. CBOR Record . . . . . . . . . . . . . . . . . . . . . . . 9 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. CBOR Tag . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. JSON Record . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. CBOR Record with explicit CM indicator . . . . . . . . . 10 4.2. CBOR Record . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. CBOR Collection . . . . . . . . . . . . . . . . . . . . . 11 4.3. CBOR Tag . . . . . . . . . . . . . . . . . . . . . . . . 11
4.6. JSON Collection . . . . . . . . . . . . . . . . . . . . . 12 4.4. CBOR Record with explicit CM indicator . . . . . . . . . 11
4.7. Use in JWT . . . . . . . . . . . . . . . . . . . . . . . 13 4.5. CBOR Collection . . . . . . . . . . . . . . . . . . . . . 12
5. Transporting CMW in X.509 Messages . . . . . . . . . . . . . 14 4.6. JSON Collection . . . . . . . . . . . . . . . . . . . . . 13
5.1. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 14 4.7. Use in JWT . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Compatibility with DICE ConceptualMessageWrapper . . . . 15 5. Transporting CMW in X.509 Messages . . . . . . . . . . . . . 15
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 5.1. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Project Veraison . . . . . . . . . . . . . . . . . . . . 16 5.2. Compatibility with DICE ConceptualMessageWrapper . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6.1. Project Veraison . . . . . . . . . . . . . . . . . . . . 17
8.1. CWT cmw Claim Registration . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8.2. JWT cmw Claim Registration . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8.3. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 18 8.1. CWT cmw Claim Registration . . . . . . . . . . . . . . . 18
8.2. JWT cmw Claim Registration . . . . . . . . . . . . . . . 18
8.3. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 19
8.4. RATS Conceptual Message Wrapper (CMW) Indicators 8.4. RATS Conceptual Message Wrapper (CMW) Indicators
Registry . . . . . . . . . . . . . . . . . . . . . . . . 18 Registry . . . . . . . . . . . . . . . . . . . . . . . . 19
8.4.1. Instructions for the Designated Expert . . . . . . . 18 8.4.1. Instructions for the Designated Expert . . . . . . . 19
8.4.2. Structure of Entries . . . . . . . . . . . . . . . . 18 8.4.2. Structure of Entries . . . . . . . . . . . . . . . . 19
8.5. Media Types . . . . . . . . . . . . . . . . . . . . . . . 19 8.4.3. Provisional Registration . . . . . . . . . . . . . . 20
8.5.1. application/cmw+cbor . . . . . . . . . . . . . . . . 19 8.5. Media Types . . . . . . . . . . . . . . . . . . . . . . . 20
8.5.2. application/cmw+json . . . . . . . . . . . . . . . . 20 8.5.1. application/cmw+cbor . . . . . . . . . . . . . . . . 21
8.6. New SMI Numbers Registrations . . . . . . . . . . . . . . 20 8.5.2. application/cmw+json . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.6. CoAP Content Formats . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . 21 8.7. New SMI Numbers Registrations . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
Appendix A. Collected CDDL . . . . . . . . . . . . . . . . . . . 24 9.1. Normative References . . . . . . . . . . . . . . . . . . 22
Appendix B. Registering and Using CMWs . . . . . . . . . . . . . 26 9.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 27 Appendix A. Collected CDDL . . . . . . . . . . . . . . . . . . . 26
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27 Appendix B. Registering and Using CMWs . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 29
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
The RATS architecture defines a handful of conceptual messages (see The RATS architecture defines a handful of conceptual messages (see
Section 8 of [RFC9334]), such as Evidence and Attestation Results. Section 8 of [RFC9334]), such as Evidence and Attestation Results.
Each conceptual message can have multiple claims encoding and Each conceptual message can have multiple claims encoding and
serialization formats (Section 9 of [RFC9334]). Throughout their serialization formats (Section 9 of [RFC9334]). Throughout their
lifetime, RATS conceptual messages are typically transported over lifetime, RATS conceptual messages are typically transported over
different protocols. For example, different protocols. For example,
skipping to change at page 5, line 29 skipping to change at page 5, line 32
The collected CDDL is in Appendix A. The collected CDDL is in Appendix A.
3.1. CMW Record 3.1. CMW Record
The format of the CMW record is shown in Figure 1. The JSON [STD90] The format of the CMW record is shown in Figure 1. The JSON [STD90]
and CBOR [STD94] representations are provided separately. Both the and CBOR [STD94] representations are provided separately. Both the
json-record and cbor-record have the same fields except for slight json-record and cbor-record have the same fields except for slight
differences in the types discussed below. differences in the types discussed below.
A CMW record carried in a "cmw" JWT claim (Section 8.2) MUST be a
json-record. A CMW record carried in a "cmw" CWT claim (Section 8.1)
MUST be a cbor-record.
json-record = [ json-record = [
type: media-type type: media-type
value: base64-string value: base64-string
? ind: uint .bits cm-type ? ind: uint .bits cm-type
] ]
cbor-record = [ cbor-record = [
type: coap-content-format-type / media-type type: coap-content-format-type / media-type
value: bytes value: bytes
? ind: uint .bits cm-type ? ind: uint .bits cm-type
skipping to change at page 6, line 39 skipping to change at page 6, line 46
CBOR Tags used as CMW may be derived from CoAP Content-Format CBOR Tags used as CMW may be derived from CoAP Content-Format
numbers. If a CoAP content format exists for a RATS conceptual numbers. If a CoAP content format exists for a RATS conceptual
message, the TN() transform defined in Appendix B of [RFC9277] can be message, the TN() transform defined in Appendix B of [RFC9277] can be
used to derive a corresponding CBOR tag in range [1668546817, used to derive a corresponding CBOR tag in range [1668546817,
1668612095]. 1668612095].
The RATS conceptual message is first serialized according to the The RATS conceptual message is first serialized according to the
Content-Format number associated with the CBOR tag and then encoded Content-Format number associated with the CBOR tag and then encoded
as a CBOR byte string, to which the tag is prepended. as a CBOR byte string, to which the tag is prepended.
The CMW CBOR Tag is defined in Figure 2. The CMW CBOR Tag is defined in Figure 2 as a macro with two
parameters:
cbor-tag = #6.<0..18446744073709551615>(bytes) * tn, the CBOR tag number
Figure 2: CDDL definition of the CBOR Tag format * $fmt, the definition of the associated conceptual message
cbor-tag<tn, $fmt> = #6.<tn>(bytes .cbor $fmt)
Figure 2: CDDL definition of the CBOR Tag format macro
To add a new CMW, the $cbor-tag type socket is extended with a new
instance of the CMW CBOR Tag macro. For example, to associate
conceptual messages of type my-evidence with CBOR Tag 1668576819, one
would extend $cbor-tag as follows:
$cbor-tag /= cbor-tag<1668576819, my-evidence>
my-evidence = {
&(eat_nonce: 10) => bstr .size (8..64)
}
3.2.1. Use of Pre-existing CBOR Tags 3.2.1. Use of Pre-existing CBOR Tags
If a CBOR tag has been registered in association with a certain RATS If a CBOR tag has been registered in association with a certain RATS
conceptual message independently of a CoAP content format (i.e., it conceptual message independently of a CoAP content format (i.e., it
is not obtained by applying the TN() transform), it can be readily is not obtained by applying the TN() transform), it can be readily
used as an encapsulation without the extra processing described in used as an encapsulation without the extra processing described in
Section 3.2. Section 3.2.
A consumer can always distinguish tags that have been derived via A consumer can always distinguish tags that have been derived via
skipping to change at page 7, line 28 skipping to change at page 8, line 8
booted on a SmartNIC plugged into a PCIe slot, and a third AE might 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. measure and attest to what was booted on the machine's GPU.
To address the composite Attester use case, this document defines a To address the composite Attester use case, this document defines a
CMW "collection" as a container that holds several CMW items, each CMW "collection" as a container that holds several CMW items, each
with a label that is unique within the scope of the collection. 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 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 with CMW values, either native or "tunnelled" (Section 3.4). The
position of a cmw entry in the cmw-collection is not significant. position of a cmw entry in the cmw-collection is not significant.
Instead, the labels identify a conceptual message that, in the case Labels can be strings (or integers in the CBOR serialization) that
of a composite Attester, should typically correspond to a component serve as a mnemonic for different conceptual messages in the
of a system. Labels can be strings (or integers in the CBOR collection.
serialization) that serve as a mnemonic for different conceptual
messages in the collection. The "__cmwc_t" key is reserved for The "__cmwc_t" key is reserved for associating an optional type to
associating an optional type to the overall collection and MUST NOT the overall collection and MUST NOT be used for a label. The
be used for a label. The collection type is either a Uniform collection type is either a Uniform Resource Identifier (URI) or an
Resource Identifier (URI) or an object identifier (OID). The OID is object identifier (OID). The OID is always absolute and never
always absolute and never relative. relative.
Since the collection type is recursive, implementations may limit the Since the collection type is recursive, implementations may limit the
allowed depth of nesting. allowed depth of nesting.
json-collection = { json-collection = {
? "__cmwc_t": ~uri / oid ? "__cmwc_t": ~uri / oid
+ text => json-CMW / c2j-tunnel + &(label: text) => json-CMW / c2j-tunnel
} }
cbor-collection = { cbor-collection = {
? "__cmwc_t": ~uri / oid ? "__cmwc_t": ~uri / oid
+ (int / text) => cbor-CMW / j2c-tunnel + &(label: (int / text)) => cbor-CMW / j2c-tunnel
} }
Figure 3: CDDL definition of the CMW collection format Figure 3: CDDL definition of the CMW collection format
Although initially designed for the composite Attester use case, the Although initially designed for the composite Attester use case, the
CMW collection can be repurposed for other use cases requiring CMW CMW collection can be repurposed for other use cases requiring CMW
aggregation. aggregation.
A CMW collection carried in a "cmw" JWT claim (Section 8.2) MUST be a
json-collection. A CMW collection carried in a "cmw" CWT claim
(Section 8.1) MUST be a cbor-collection.
3.3.1. CMW Collections' role in composite Attester topology
A CMW Collection's tree structure is not required to be a spanning
tree of the system's composite Attester topology. If the labels
carry semantic content for a Verifier (e.g. to improve Verifier
performance or aid human comprehension), the collection SHOULD be
integrity protected. For example, the collection can be integrity
protected by including it in a signed token such as a CWT or JWT.
3.4. CMW Tunnel 3.4. CMW Tunnel
The CMW tunnel type (Figure 4) allows for moving a CMW in one The CMW tunnel type (Figure 4) allows for moving a CMW in one
serialization format, either JSON or CBOR, into a collection that serialization format, either JSON or CBOR, into a collection that
uses the opposite serialization format. uses the opposite serialization format.
Both tunnel types are arrays with two elements. The first element, a Both tunnel types are arrays with two elements. The first element, a
fixed text string starting with a #, acts as a sentinel value. The fixed text string starting with a #, acts as a sentinel value. The
#, which is not an acceptable start symbol for the Content-Type #, which is not an acceptable start symbol for the Content-Type
production (Appendix A), makes it possible to disambiguate a CMW production (Appendix A), makes it possible to disambiguate a CMW
skipping to change at page 9, line 34 skipping to change at page 10, line 34
4. Examples 4. Examples
The (equivalent) examples in Section 4.1, Section 4.2, and The (equivalent) examples in Section 4.1, Section 4.2, and
Section 4.3 assume that the Media-Type-Name application/ Section 4.3 assume that the Media-Type-Name application/
vnd.example.rats-conceptual-msg has been registered alongside a vnd.example.rats-conceptual-msg has been registered alongside a
corresponding CoAP Content-Format number 30001. The CBOR tag corresponding CoAP Content-Format number 30001. The CBOR tag
1668576818 is derived applying the TN() transform as described in 1668576818 is derived applying the TN() transform as described in
Section 3.2. Section 3.2.
The example in Section 4.4 is a signed CoRIM payload with an explicit The example in Section 4.4 is a signed CoRIM (Concise Reference
CM indicator 0b0000_0011 (3), meaning that the wrapped message Integrity Manifest) [I-D.ietf-rats-corim] payload with an explicit CM
contains both Reference Values and Endorsements. indicator 0b0000_0011 (3), meaning that the wrapped message contains
both Reference Values and Endorsements.
4.1. JSON Record 4.1. JSON Record
[ [
"application/vnd.example.rats-conceptual-msg", "application/vnd.example.rats-conceptual-msg",
"q82rzQ" "q82rzQ"
] ]
Note that a CoAP Content-Format number can also be used with the JSON 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 record form. That may be the case when it is known that the receiver
skipping to change at page 13, line 35 skipping to change at page 14, line 35
4 4
], ],
"attester B (tunnelled)": [ "attester B (tunnelled)": [
"#cmw-c2j-tunnel", "#cmw-c2j-tunnel",
"g3gYYXBwbGljYXRpb24vZWF0LXVjcytjYm9yQaAE" "g3gYYXBwbGljYXRpb24vZWF0LXVjcytjYm9yQaAE"
] ]
} }
4.7. Use in JWT 4.7. Use in JWT
The following example shows the use of the cmw JWT claim to transport The following example shows the use of the "cmw" JWT claim to
a CMW collection in a JWT [RFC7519]: transport a CMW collection in a JWT [RFC7519]:
{ {
"cmw": { "cmw": {
"attester A": [ "attester A": [
"application/eat-ucs+json", "application/eat-ucs+json",
"e30K", "e30K",
4 4
], ],
"attester B (tunnelled)": [ "attester B (tunnelled)": [
"#cmw-c2j-tunnel", "#cmw-c2j-tunnel",
"g3gYYXBwbGljYXRpb24vZWF0LXVjcytjYm9yQaAE" "g3gYYXBwbGljYXRpb24vZWF0LXVjcytjYm9yQaAE"
] ]
}, },
"iss": "evidence collection daemon", "iss": "evidence collection daemon",
"exp": 1300819380 "exp": 1300819380
} }
5. Transporting CMW in X.509 Messages 5. Transporting CMW in X.509 Messages
There are cases where CMW need to be transported in PKIX messages, CMW may need to be transported in PKIX messages, such as Certificate
for example in Certificate Signing Requests (CSRs) Signing Requests (CSRs) or in X.509 Certificates and Certificate
[I-D.ietf-lamps-csr-attestation], or in X.509 Certificates and Revocation Lists (CRLs). The former use is documented in
Certificate Revocation Lists (CRLs) [DICE-arch]. [I-D.ietf-lamps-csr-attestation], the latter in Section 6.1 of
[DICE-arch].
This section specifies the CMW extension to carry CMW objects. This section specifies the CMW extension to carry CMW objects.
The CMW extension MAY be included in X.509 Certificates, CRLs The CMW extension MAY be included in X.509 Certificates, CRLs
[RFC5280], and CSRs. [RFC5280], and CSRs.
The CMW extension MUST be identified by the following object The CMW extension MUST be identified by the following object
identifier: identifier:
id-pe-cmw-collection OBJECT IDENTIFIER ::= id-pe-cmw OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-pe(1) TBD } security(5) mechanisms(5) pkix(7) id-pe(1) TBD }
This extension MUST NOT be marked critical. 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: The CMW extension MUST have the following syntax:
CMW ::= CHOICE { CMW ::= CHOICE {
json UTF8String, json UTF8String,
cbor OCTET STRING cbor OCTET STRING
} }
The CMW MUST contain the serialized CMW object in JSON or CBOR The CMW MUST contain the serialized CMW object in JSON or CBOR
format, using the appropriate CHOICE entry. format, using the appropriate CHOICE entry.
skipping to change at page 15, line 24 skipping to change at page 16, line 24
EXTENSION EXTENSION
FROM PKIX-CommonTypes-2009 -- RFC 5912 FROM PKIX-CommonTypes-2009 -- RFC 5912
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) } ; id-mod-pkixCommon-02(57) } ;
-- CMW Extension -- CMW Extension
ext-CMW EXTENSION ::= { ext-CMW EXTENSION ::= {
SYNTAX CMW SYNTAX CMW
IDENTIFIED BY id-pe-cmw-collection } IDENTIFIED BY id-pe-cmw }
-- CMW Extension OID -- CMW Extension OID
id-pe-cmw-collection OBJECT IDENTIFIER ::= id-pe-cmw OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-pe(1) TBD } security(5) mechanisms(5) pkix(7) id-pe(1) TBD }
-- CMW Extension Syntax -- CMW Extension Syntax
CMW ::= CHOICE { CMW ::= CHOICE {
json UTF8String, json UTF8String,
cbor OCTET STRING cbor OCTET STRING
} }
skipping to change at page 16, line 43 skipping to change at page 17, line 43
The software, hosted at https://github.com/veraison/cmw, provides a The software, hosted at https://github.com/veraison/cmw, provides a
Golang package that allows encoding and decoding of CMW payloads. Golang package that allows encoding and decoding of CMW payloads.
The implementation covers all the features presented in this draft. The implementation covers all the features presented in this draft.
The maturity level is alpha. The license is Apache 2.0. The The maturity level is alpha. The license is Apache 2.0. The
developers can be contacted on the Zulip channel: developers can be contacted on the Zulip channel:
https://veraison.zulipchat.com/#narrow/stream/383526-CMW/. https://veraison.zulipchat.com/#narrow/stream/383526-CMW/.
7. Security Considerations 7. Security Considerations
This document introduces two encapsulation formats for RATS This document introduces two encapsulation formats for RATS
conceptual messages. RATS conceptual messages are typically secured conceptual messages, record and tag. RATS conceptual messages are
using cryptography. If the messages are already protected, then typically secured using cryptography. If the messages are already
there are no additional security requirements imposed by the protected, then there are no additional security requirements imposed
introduction of this encapsulation. If an adversary tries to modify by the introduction of this encapsulation. If an adversary tries to
the payload encapsulation, it will result in incorrect processing of modify the payload encapsulation, it will result in incorrect
the encapsulated message and lead to an error. If the messages are processing of the encapsulated message and lead to an error. If the
not protected, additional security must be added at a different messages are not protected, additional security must be added at a
layer. As an example, a CMW record containing an UCCS different layer. As an example, a cbor-record containing an UCCS
[I-D.ietf-rats-uccs] can be signed using COSE Sign1 [STD96]. (Unprotected CWT Claims Sets) [I-D.ietf-rats-uccs] can be signed
using COSE Sign1 [STD96].
This document introduces a format for holding multiple CMW items in a This document introduces a format for holding multiple CMW items in a
collection. If the collection is not protected from tampering by collection. If the collection is not protected from tampering by
external security measures (such as object security primitives) or external security measures (such as object security primitives) or
internal mechanisms (such as intra-item binding), an attacker could internal mechanisms (such as intra-item binding), an attacker could
easily manipulate the collection's contents. easily manipulate the collection's contents.
8. IANA Considerations 8. IANA Considerations
// RFC Editor: replace "RFCthis" with the RFC number assigned to this // RFC Editor: replace "RFCthis" with the RFC number assigned to this
skipping to change at page 17, line 31 skipping to change at page 18, line 31
* Claim Name: cmw * Claim Name: cmw
* Claim Description: A RATS Conceptual Message Wrapper * Claim Description: A RATS Conceptual Message Wrapper
* Claim Key: TBD * Claim Key: TBD
* Claim Value Type(s): CBOR Map, CBOR Array, or CBOR Tag * Claim Value Type(s): CBOR Map, CBOR Array, or CBOR Tag
* Change Controller: IETF * Change Controller: IETF
* Specification Document(s): Section 3.1 and Section 3.2 of RFCthis * Specification Document(s): Section 3.1, Section 3.3 and
Section 3.2 of RFCthis
The suggested value for the Claim Key is 299. The suggested value for the Claim Key is 299.
8.2. JWT cmw Claim Registration 8.2. JWT cmw Claim Registration
IANA is requested to add a new cmw claim to the "JSON Web Token IANA is requested to add a new cmw claim to the "JSON Web Token
Claims" sub-registry of the "JSON Web Token (JWT)" registry Claims" sub-registry of the "JSON Web Token (JWT)" registry
[IANA.jwt] as follows: [IANA.jwt] as follows:
* Claim Name: cmw * Claim Name: cmw
* Claim Description: A RATS Conceptual Message Wrapper * Claim Description: A RATS Conceptual Message Wrapper
* Claim Value Type(s): JSON Object or JSON Array
* Change Controller: IETF * Change Controller: IETF
* Specification Document(s): Section 3.1 of RFCthis * Specification Document(s): Section 3.1 and Section 3.3 of RFCthis
8.3. CBOR Tag Registration 8.3. CBOR Tag Registration
IANA is requested to add the following tag to the "CBOR Tags" IANA is requested to add the following tag to the "CBOR Tags"
[IANA.cbor-tags] registry. [IANA.cbor-tags] registry.
+======+=================+=================+========================+ +======+=================+=================+========================+
| CBOR | Data Item | Semantics | Reference | | CBOR | Data Item | Semantics | Reference |
| Tag | | | | | Tag | | | |
+======+=================+=================+========================+ +======+=================+=================+========================+
skipping to change at page 18, line 27 skipping to change at page 19, line 27
+------+-----------------+-----------------+------------------------+ +------+-----------------+-----------------+------------------------+
Table 1 Table 1
8.4. RATS Conceptual Message Wrapper (CMW) Indicators Registry 8.4. RATS Conceptual Message Wrapper (CMW) Indicators Registry
This specification defines a new "RATS Conceptual Message Wrapper This specification defines a new "RATS Conceptual Message Wrapper
(CMW) Indicators" registry, with the policy "Expert Review" (CMW) Indicators" registry, with the policy "Expert Review"
(Section 4.5 of [BCP26]). (Section 4.5 of [BCP26]).
The objective is to have Indicators values registered for all RATS The objective is to have CMW Indicators values registered for all
Conceptual Messages (Section 8 of [RFC9334]). RATS Conceptual Messages (Section 8 of [RFC9334]).
8.4.1. Instructions for the Designated Expert 8.4.1. Instructions for the Designated Expert
The expert is instructed to add the values incrementally. The expert is instructed to add the values incrementally.
Acceptable values are those corresponding to RATS Conceptual Messages Acceptable values are those corresponding to RATS Conceptual Messages
defined by the RATS architecture [RFC9334] and any of its updates. defined by the RATS architecture [RFC9334] and any of its updates.
8.4.2. Structure of Entries 8.4.2. Structure of Entries
Each entry in the registry must include: Each entry in the registry must include:
Indicator value: Indicator value:
A number corresponding to the bit position in the cm-ind bitmap. A number corresponding to the bit position in the ind bitmap
(Section 3.1).
Conceptual Message name: Conceptual Message name:
A text string describing the RATS conceptual message this A text string describing the RATS conceptual message this
indicator corresponds to. indicator corresponds to.
Reference: Reference:
A reference to a document, if available, or the registrant. A reference to a document, if available, or the registrant.
The initial registrations for the registry are detailed in Table 2. The initial registrations for the registry are detailed in Table 2.
skipping to change at page 19, line 16 skipping to change at page 20, line 16
| Indicator value | Conceptual Message name | Reference | | Indicator value | Conceptual Message name | Reference |
+=================+=========================+===========+ +=================+=========================+===========+
| 0 | Reference Values | RFCthis | | 0 | Reference Values | RFCthis |
+-----------------+-------------------------+-----------+ +-----------------+-------------------------+-----------+
| 1 | Endorsements | RFCthis | | 1 | Endorsements | RFCthis |
+-----------------+-------------------------+-----------+ +-----------------+-------------------------+-----------+
| 2 | Evidence | RFCthis | | 2 | Evidence | RFCthis |
+-----------------+-------------------------+-----------+ +-----------------+-------------------------+-----------+
| 3 | Attestation Results | RFCthis | | 3 | Attestation Results | RFCthis |
+-----------------+-------------------------+-----------+ +-----------------+-------------------------+-----------+
| 4-31 | Unassigned | RFCthis |
+-----------------+-------------------------+-----------+
Table 2: CMW Indicators Registry Initial Contents Table 2: CMW Indicators Registry Initial Contents
8.4.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.
8.5. Media Types 8.5. Media Types
IANA is requested to add the following media types to the "Media IANA is requested to add the following media types to the "Media
Types" registry [IANA.media-types]. Types" registry [IANA.media-types].
+==========+======================+============================+ +==========+======================+============================+
| Name | Template | Reference | | Name | Template | Reference |
+==========+======================+============================+ +==========+======================+============================+
| cmw+cbor | application/cmw+cbor | Section 3.1, Section 3.2 | | cmw+cbor | application/cmw+cbor | Section 3.1, Section 3.2 |
| | | and Section 3.3 of RFCthis | | | | and Section 3.3 of RFCthis |
skipping to change at page 20, line 41 skipping to change at page 22, line 10
fragment identifiers are as specified for "application/json". (No fragment identifiers are as specified for "application/json". (No
fragment identification syntax is currently defined for fragment identification syntax is currently defined for
"application/json".) "application/json".)
Person & email address to contact for further information: RATS WG Person & email address to contact for further information: RATS WG
mailing list (rats@ietf.org) mailing list (rats@ietf.org)
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author/Change controller: IETF Author/Change controller: IETF
Provisional registration: no Provisional registration: no
8.6. New SMI Numbers Registrations 8.6. CoAP Content Formats
IANA is requested to register the following Content-Format numbers in
the "CoAP Content-Formats" sub-registry, within the "Constrained
RESTful Environments (CoRE) Parameters" Registry
[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 |
+--------------+----------------+------+----------------------------+
Table 4: New CoAP Content Formats
If possible, TBD1 and TBD2 should be assigned in the 256..999 range.
8.7. New SMI Numbers Registrations
IANA is requested to assign an object identifier (OID) for the CMW IANA is requested to assign an object identifier (OID) for the CMW
extension defined in Section 5 in the "Certificate Extension" sub- extension defined in Section 5 in the "Certificate Extension" sub-
registry of the "SMI Numbers" [IANA.smi-numbers] registry. registry of the "SMI Numbers" [IANA.smi-numbers] registry.
IANA is requested to assign an object identifier (OID) for the ASN.1 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 Module defined in Section 5.1 in the "Module Identifier" sub-registry
of the "SMI Numbers" [IANA.smi-numbers] registry. of the "SMI Numbers" [IANA.smi-numbers] registry.
9. References 9. References
skipping to change at page 21, line 4 skipping to change at page 22, line 43
IANA is requested to assign an object identifier (OID) for the CMW IANA is requested to assign an object identifier (OID) for the CMW
extension defined in Section 5 in the "Certificate Extension" sub- extension defined in Section 5 in the "Certificate Extension" sub-
registry of the "SMI Numbers" [IANA.smi-numbers] registry. registry of the "SMI Numbers" [IANA.smi-numbers] registry.
IANA is requested to assign an object identifier (OID) for the ASN.1 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 Module defined in Section 5.1 in the "Module Identifier" sub-registry
of the "SMI Numbers" [IANA.smi-numbers] registry. of the "SMI Numbers" [IANA.smi-numbers] registry.
9. References 9. References
9.1. Normative References 9.1. Normative References
[BCP26] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [BCP26] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>. <https://www.rfc-editor.org/rfc/rfc8126>.
[IANA.cbor-tags] [IANA.cbor-tags]
IANA, "Concise Binary Object Representation (CBOR) Tags", IANA, "Concise Binary Object Representation (CBOR) Tags",
<http://www.iana.org/assignments/cbor-tags>. <http://www.iana.org/assignments/cbor-tags>.
[IANA.core-parameters]
IANA, "Constrained RESTful Environments (CoRE)
Parameters",
<http://www.iana.org/assignments/core-parameters>.
[IANA.cwt] IANA, "CBOR Web Token (CWT) Claims", [IANA.cwt] IANA, "CBOR Web Token (CWT) Claims",
<http://www.iana.org/assignments/cwt>. <http://www.iana.org/assignments/cwt>.
[IANA.jwt] IANA, "JSON Web Token (JWT)", [IANA.jwt] IANA, "JSON Web Token (JWT)",
<http://www.iana.org/assignments/jwt>. <http://www.iana.org/assignments/jwt>.
[IANA.media-types] [IANA.media-types]
IANA, "Media Types", IANA, "Media Types",
<http://www.iana.org/assignments/media-types>. <http://www.iana.org/assignments/media-types>.
skipping to change at page 23, line 24 skipping to change at page 25, line 24
9.2. Informative References 9.2. Informative References
[DICE-arch] [DICE-arch]
Trusted Computing Group, "DICE Attestation Architecture", Trusted Computing Group, "DICE Attestation Architecture",
January 2024, <https://trustedcomputinggroup.org/wp- January 2024, <https://trustedcomputinggroup.org/wp-
content/uploads/DICE-Attestation-Architecture-Version-1.1- content/uploads/DICE-Attestation-Architecture-Version-1.1-
Revision-18_pub.pdf>. Revision-18_pub.pdf>.
[I-D.fossati-tls-attestation] [I-D.fossati-tls-attestation]
Tschofenig, H., Sheffer, Y., Howard, P., Mihalcea, I., and Tschofenig, H., Sheffer, Y., Howard, P., Mihalcea, I.,
Y. Deshpande, "Using Attestation in Transport Layer Deshpande, Y., Niemi, A., and T. Fossati, "Using
Security (TLS) and Datagram Transport Layer Security Attestation in Transport Layer Security (TLS) and Datagram
(DTLS)", Work in Progress, Internet-Draft, draft-fossati- Transport Layer Security (DTLS)", Work in Progress,
tls-attestation-04, 23 October 2023, Internet-Draft, draft-fossati-tls-attestation-06, 19 March
<https://datatracker.ietf.org/doc/html/draft-fossati-tls- 2024, <https://datatracker.ietf.org/doc/html/draft-
attestation-04>. fossati-tls-attestation-06>.
[I-D.ietf-lamps-csr-attestation] [I-D.ietf-lamps-csr-attestation]
Ounsworth, M., Tschofenig, H., and H. Birkholz, "Use of Ounsworth, M., Tschofenig, H., Birkholz, H., and M.
Remote Attestation with Certificate Signing Requests", Wiseman, "Use of Remote Attestation with Certification
Work in Progress, Internet-Draft, draft-ietf-lamps-csr- Signing Requests", Work in Progress, Internet-Draft,
attestation-05, 13 February 2024, draft-ietf-lamps-csr-attestation-09, 10 May 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps- <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
csr-attestation-05>. csr-attestation-09>.
[I-D.ietf-rats-ar4si] [I-D.ietf-rats-ar4si]
Voit, E., Birkholz, H., Hardjono, T., Fossati, T., and V. Voit, E., Birkholz, H., Hardjono, T., Fossati, T., and V.
Scarlata, "Attestation Results for Secure Interactions", Scarlata, "Attestation Results for Secure Interactions",
Work in Progress, Internet-Draft, draft-ietf-rats-ar4si- Work in Progress, Internet-Draft, draft-ietf-rats-ar4si-
05, 30 August 2023, 06, 4 March 2024, <https://datatracker.ietf.org/doc/html/
<https://datatracker.ietf.org/doc/html/draft-ietf-rats- draft-ietf-rats-ar4si-06>.
ar4si-05>.
[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-04, 4
March 2024, <https://datatracker.ietf.org/doc/html/draft-
ietf-rats-corim-04>.
[I-D.ietf-rats-eat] [I-D.ietf-rats-eat]
Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "The Entity Attestation Token (EAT)", Work in Wallace, "The Entity Attestation Token (EAT)", Work in
Progress, Internet-Draft, draft-ietf-rats-eat-25, 15 Progress, Internet-Draft, draft-ietf-rats-eat-28, 25 June
January 2024, <https://datatracker.ietf.org/doc/html/ 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
draft-ietf-rats-eat-25>. rats-eat-28>.
[I-D.ietf-rats-eat-media-type] [I-D.ietf-rats-eat-media-type]
Lundblade, L., Birkholz, H., and T. Fossati, "EAT Media Lundblade, L., Birkholz, H., and T. Fossati, "EAT Media
Types", Work in Progress, Internet-Draft, draft-ietf-rats- Types", Work in Progress, Internet-Draft, draft-ietf-rats-
eat-media-type-05, 7 November 2023, eat-media-type-07, 2 April 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats- <https://datatracker.ietf.org/doc/html/draft-ietf-rats-
eat-media-type-05>. eat-media-type-07>.
[I-D.ietf-rats-uccs] [I-D.ietf-rats-uccs]
Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C. Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C.
Bormann, "A CBOR Tag for Unprotected CWT Claims Sets", Bormann, "A CBOR Tag for Unprotected CWT Claims Sets",
Work in Progress, Internet-Draft, draft-ietf-rats-uccs-08, Work in Progress, Internet-Draft, draft-ietf-rats-uccs-09,
16 January 2024, <https://datatracker.ietf.org/doc/html/ 4 March 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-uccs-08>. draft-ietf-rats-uccs-09>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205, Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016, RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/rfc/rfc7942>. <https://www.rfc-editor.org/rfc/rfc7942>.
[RFC9193] Keränen, A. and C. Bormann, "Sensor Measurement Lists [RFC9193] Keränen, A. and C. Bormann, "Sensor Measurement Lists
(SenML) Fields for Indicating Data Value Content-Format", (SenML) Fields for Indicating Data Value Content-Format",
RFC 9193, DOI 10.17487/RFC9193, June 2022, RFC 9193, DOI 10.17487/RFC9193, June 2022,
<https://www.rfc-editor.org/rfc/rfc9193>. <https://www.rfc-editor.org/rfc/rfc9193>.
skipping to change at page 25, line 9 skipping to change at page 27, line 9
Structures and Process", STD 96, RFC 9052, Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022, DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/rfc/rfc9052>. <https://www.rfc-editor.org/rfc/rfc9052>.
Appendix A. Collected CDDL Appendix A. Collected CDDL
start = cmw start = cmw
cmw = json-CMW / cbor-CMW cmw = json-CMW / cbor-CMW
json-CMW = json-record / json-collection json-CMW = json-record / json-collection
cbor-CMW = cbor-record / cbor-collection / cbor-tag cbor-CMW = cbor-record / cbor-collection / $cbor-tag
json-record = [ json-record = [
type: media-type type: media-type
value: base64-string value: base64-string
? ind: uint .bits cm-type ? ind: uint .bits cm-type
] ]
cbor-record = [ cbor-record = [
type: coap-content-format-type / media-type type: coap-content-format-type / media-type
value: bytes value: bytes
? ind: uint .bits cm-type ? ind: uint .bits cm-type
] ]
cbor-tag = #6.<0..18446744073709551615>(bytes) cbor-tag<tn, $fmt> = #6.<tn>(bytes .cbor $fmt)
json-collection = { json-collection = {
? "__cmwc_t": ~uri / oid ? "__cmwc_t": ~uri / oid
+ text => json-CMW / c2j-tunnel + &(label: text) => json-CMW / c2j-tunnel
} }
cbor-collection = { cbor-collection = {
? "__cmwc_t": ~uri / oid ? "__cmwc_t": ~uri / oid
+ (int / text) => cbor-CMW / j2c-tunnel + &(label: (int / text)) => cbor-CMW / j2c-tunnel
} }
c2j-tunnel = [ "#cmw-c2j-tunnel", base64-string ] c2j-tunnel = [ "#cmw-c2j-tunnel", base64-string ]
j2c-tunnel = [ "#cmw-j2c-tunnel", bytes ] j2c-tunnel = [ "#cmw-j2c-tunnel", bytes ]
media-type = text .abnf ("Content-Type" .cat Content-Type-ABNF) media-type = text .abnf ("Content-Type" .cat Content-Type-ABNF)
base64-string = text .regexp "[A-Za-z0-9_-]+" base64-string = text .regexp "[A-Za-z0-9_-]+"
cm-type = &( cm-type = &(
reference-values: 0 reference-values: 0
skipping to change at page 27, line 45 skipping to change at page 29, line 45
Appendix C. Open Issues Appendix C. Open Issues
The list of currently open issues for this documents can be found at The list of currently open issues for this documents can be found at
https://github.com/thomas-fossati/draft-ftbs-rats-msg-wrap/issues. https://github.com/thomas-fossati/draft-ftbs-rats-msg-wrap/issues.
// Note to RFC Editor: please remove before publication. // Note to RFC Editor: please remove before publication.
Acknowledgments Acknowledgments
The authors would like to thank Carl Wallace, Carsten Bormann, Dionna The authors would like to thank Brian Campbell, Carl Wallace, Carsten
Glaze, Laurence Lundblade, Russ Housley, and Tom Jones for their Bormann, Dionna Glaze, Laurence Lundblade, Mike Jones, Mohit Sethi,
reviews and suggestions. Russ Housley, and Tom Jones for their reviews and suggestions.
The definition of a CMW collection has been modelled on a proposal The definition of a CMW collection has been modelled on a proposal
originally made by Simon Frost for an EAT-based Evidence collection originally made by Simon Frost for an EAT-based Evidence collection
type. The CMW collection intentionally attains binary compatibility type. The CMW collection intentionally attains binary compatibility
with Simon's design and aims at superseding it by also generalizing with Simon's design and aims at superseding it by also generalizing
on the allowed Evidence formats. on the allowed Evidence formats.
Authors' Addresses Authors' Addresses
Henk Birkholz Henk Birkholz
 End of changes. 46 change blocks. 
116 lines changed or deleted 208 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/