]> Fraunhofer SIT

henk.birkholz@ietf.contact

Independent

ned.smith.ietf@outlook.com

Linaro

thomas.fossati@linaro.org

University of Applied Sciences Bonn-Rhein-Sieg

Hannes.Tschofenig@gmx.net

Google LLC

dionnaglaze@google.com

Security Remote ATtestation ProcedureS evidence attestation results endorsements reference values The Conceptual Messages introduced by the RATS architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during remote attestation procedures. Conceptual Messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of Conceptual Messages is defined in Section 8 of RFC 9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated CBOR tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. This allows CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts like X.509 certificates. Additionally, the draft defines a media type and a CoAP content format to transport CMWs over protocols like HTTP, MIME, and CoAP. The goal is to improve the interoperability and flexibility of remote attestation protocols. By introducing a shared message format like the CMW, we can consistently support different attestation message types, evolve message serialization formats without breaking compatibility, and avoid having to redefine how messages are handled in each protocol. Discussion Venues Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (rats@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction The Conceptual Messages introduced by the Remote ATtestation procedureS (RATS) architecture are protocol-agnostic data units that are conveyed between RATS roles during remote attestation procedures. Conceptual Messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of Conceptual Messages is defined in and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. Each conceptual message can have multiple claims encoding and serialization formats (). Throughout their lifetime, RATS conceptual messages are typically transported over different protocols. For example,

• In a "background check" topology, Evidence (e.g., 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) ) 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 , which allows the cost of their registration to be spread across numerous usage scenarios.

A protocol designer could use these formats, for example, to convey Evidence, Endorsements and Reference Values in certificates and CRLs extensions (), to embed Attestation Results or Evidence as first-class authentication credentials in TLS handshake messages , 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 formats and protocols. In addition, a Media Type and a CoAP Content-Format are defined for transporting CMWs in HTTP, MIME, CoAP and other Internet protocols.

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 when, and only when, they appear in all capitals, as shown here. In this document, CDDL is used to describe the data formats. The reader is assumed to be familiar with the vocabulary and concepts defined in . This document reuses the terms defined in (e.g., "Content-Type").

Conceptual Message Wrappers A RATS Conceptual Message Wrapper (CMW) has a tree structure. Leaf nodes are of type "Record" (), or "Tag" (). Intermediate nodes are of type "Collection" (); they hold together multiple CMW items. The following snippet outlines the productions associated with the top-level types. The complete CDDL can be found in . and describe the transport of CMWs using CBOR and JSON Web Tokens and PKIX formats, including Certificate Signing Requests (CSRs), X.509 Certificates, and Certificate Revocation Lists (CRLs). 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 .

Record CMW The format of the Record CMW is shown in . The JSON and CBOR representations are provided separately. Both the json-record and cbor-record have the same fields except for slight differences in the types discussed below.

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 ) or an unsigned integer corresponding to a CoAP Content-Format ID (). The latter is not 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 () without padding. This always applies, even if the conceptual message format is already textual (e.g., a JWT EAT). When using CBOR, the value field MUST be encoded as a CBOR byte string.

ind:

An optional bitmap with a maximum size of 4 bytes that indicates which conceptual message types are carried in the value field. Any combination (i.e., any value between 1 and 2³²-1 inclusive) is allowed. Only five bits are registered at the time of writing, so, the acceptable values are currently limited to 1 to 31. 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/rim+cose), or if the same profile identifier is shared by different conceptual messages. The value MUST be non-zero. The absence of conceptual message indicator information is indicated by omitting the ind field entirely. For further details, see .

CM Type The cm-type type is the control type for the ind field. As such, it indicates which bits are allowed to be set in the ind byte string.

CDDL definition of the CM Type

The cm-type currently has five allowed values: Reference Values, Endorsements, Evidence, Attestation Results, and Appraisal Policy, as defined in . Note that that an Appraisal Policy may refer to the appraisal of Evidence or Attestation Results, depending on whether the consumer of the conceptual message is a Verifier or a Relying Party. Future specifications that extend the RATS Conceptual Messages set can add new values to the cm-type using the process defined in .

Tag CMW Tag CMWs derive their tag numbers from a corresponding CoAP Content-Format ID using the TN() transform defined in . 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 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.

CDDL definition of the Tag CMW macros = #6.(bytes .cbor fmt) tag-cm-data = #6.(bytes) ]]>

How To Plug in a New Tag CMW To plug a new Tag CMW into the CDDL defined in , 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: 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: ]]> Note that since this specification defines no Tag CMW, the socket is currently empty.

Collection CMW Layered Attesters and composite devices (Sections and of ) 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 () 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. The "__cmwc_t" key is reserved for associating an optional type with the overall Collection and MUST NOT be used for any purpose other than described here. 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 MUST be in the absolute form (). The "__cmwc_t" key functions similar to an EAT profile claim (see ), but at a higher level. It can be used to indicate basics like CBOR serialization and COSE algorithms just as a profile in EAT does. It provides a namespace in which the collection labels are interpreted. At the higher level, it can be used to describe the allowed CMW collection assembly (this is somewhat parallel to the way EAT profiles indicate which claims are required and/or allowed). For an example of a "__cmwc_t" that is defined for a bundle of endorsements and reference values, see . Since the Collection CMW is recursive (a Collection CMW is itself a CMW), implementations MAY limit the allowed depth of nesting.

CDDL definition of the Collection CMW json-cmw } cbor-collection = { ? "__cmwc_t": ~uri / oid + &(label: (int / text)) => cbor-cmw } ]]>

Demuxing The split in the JSON/CBOR decoding path is expected to occur via the media type or content format (see and , respectively), or via the container context of the embedded CMW (see and for CWT/JWT, and for X.509). The following pseudocode illustrates how a one-byte look-ahead is sufficient to determine how to decode the remaining byte buffer. This code is provided for informational purposes only. It is not expected that implementations will follow this demuxing strategy.

Cryptographic Protection of CMWs This section highlights a number of mechanisms through which protocol designers can add data origin authentication, integrity, and, if used with a challenge-response protocol, anti-replay protection when employing CMWs. These properties must be evaluated carefully in the context of the overall security model of the protocol.

Signing CBOR CMW using COSE Sign1 A CBOR CMW can be signed using COSE . A signed-cbor-cmw is a COSE_Sign1 with the following layout: The payload MUST be the CBOR-encoded Tag, Record, or Collection CMW. int ; alg 3 => "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 ; Note: 10000 is a placeholder for the CoAP C-F codepoint corresponding ; to 'application/cmw+cbor'. This CDDL fragment needs to be updated ; (and this note removed) once the relevant C-F codepoint has been ; assigned by IANA. ]]> 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.

Signing JSON CMW using JWS A JSON CMW can be signed using JSON Web Signature (JWS) . A signed-json-cmw is a JWS object with the following layout: The payload MUST be the JSON-encoded Record, or Collection CMW. 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. For clarity, the above uses the Flattened JSON Serialization (). However, the Compact Serialization () can also be used.

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 and , respectively.

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.

Transporting CMW in PKIX Formats CMW may need to be transported in PKIX formats, 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 , while one of the possible applications in X.509 Certificates and CRLs is detailed in Section 6.1 of . This section outlines the CMW extension designed to carry CMW objects. discusses some privacy considerations related to the transport of CMW in X.509 formats. The CMW extension MAY be included in X.509 Certificates, CRLs , and CSRs. The CMW extension MUST be identified by the following object identifier: This extension SHOULD NOT be marked critical. In cases where the wrapped Conceptual Message is essential for granting resource access, and there is a risk that legacy relying parties would bypass crucial controls, it is acceptable to mark the extension as critical. The CMW extension MUST have the following syntax: 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.

ASN.1 Module This section provides an ASN.1 module for the CMW extension, following the conventions established in and .

Compatibility with DICE ConceptualMessageWrapper Section 6.1.8 of specifies the ConceptualMessageWrapper (CMW) format and its corresponding object identifier. The CMW format outlined in permits only a subset of the CMW grammar defined in this document. In particular, the Collection format cannot be encoded using DICE CMWs.

Examples The (equivalent) examples in , , and 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 . All the examples focus on the wrapping aspects. The wrapped messages are not instances of real Conceptual Messages.

JSON-encoded Record

CBOR-encoded Record with the following wire representation: 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 registered.

CBOR-encoded Tag CMW with the following wire representation:

CBOR-encoded Record with explicit CM indicator This is an example of a signed CoRIM (Concise Reference Integrity Manifest) with an explicit ind value of 0b0000_0011 (3), indicating that the wrapped message contains both Reference Values and Endorsements. with the following wire representation:

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.

JSON-encoded Collection The following example is a JSON-encoded Collection CMW that assembles Evidence from two attesters.

Use in JWT The following example shows the use of the "cmw" JWT claim to transport a Collection CMW in a JWT Claims Set :

Collected CDDL This appendix contains all the CDDL definitions included in this specification. = #6.(bytes .cbor fmt) tag-cm-data = #6.(bytes) json-collection = { ? "__cmwc_t": ~uri / oid + &(label: text) => json-cmw } 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_-]+" coap-content-format-type = uint .size 2 oid = text .regexp "([0-2])((\\.0)|(\\.[1-9][0-9]*))*" cm-type = &( reference-values: 0 endorsements: 1 evidence: 2 attestation-results: 3 appraisal-policy: 4 ) Content-Type-ABNF = ' Content-Type = Media-Type-Name *( *SP ";" *SP parameter ) parameter = token "=" ( token / quoted-string ) token = 1*tchar tchar = "!" / "#" / "$" / "%" / "&" / "\'" / "*" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA quoted-string = %x22 *( qdtext / quoted-pair ) %x22 qdtext = SP / %x21 / %x23-5B / %x5D-7E quoted-pair = "\\" ( SP / VCHAR ) Media-Type-Name = type-name "/" subtype-name type-name = restricted-name subtype-name = restricted-name restricted-name = restricted-name-first *126restricted-name-chars restricted-name-first = ALPHA / DIGIT restricted-name-chars = ALPHA / DIGIT / "!" / "#" / "$" / "&" / "-" / "^" / "_" restricted-name-chars =/ "." ; Characters before first dot always ; specify a facet name restricted-name-chars =/ "+" ; Characters after last plus always ; specify a structured syntax suffix DIGIT = %x30-39 ; 0 - 9 POS-DIGIT = %x31-39 ; 1 - 9 ALPHA = %x41-5A / %x61-7A ; A - Z / a - z SP = %x20 VCHAR = %x21-7E ; printable ASCII (no SP) ' 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 3 => "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 } ]]>

Implementation Status RFC Editor: Please remove the entire section before publication, as well as the reference to RFC 7942. 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 . 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 , "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".

Project Veraison The organization responsible for these implementations is Project Veraison, a Linux Foundation project hosted at the Confidential Computing Consortium. The organisation hosts two libraries which allow encoding, decoding, and manipulation of CMW payloads: one for the Golang ecosystem (), and one for Rust (). These implementations cover 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: .

Privacy Considerations The privacy considerations outlined in are fully applicable. In particular, when a CMW contains Personally Identifying Information (PII), which is the case for Evidence and sometimes for other conceptual messages as well, care must be taken to prevent unintended recipients from accessing it. Generally, utilizing secure channels between the parties exchanging CMWs can help address or mitigate these concerns. A specific scenario arises when a public key certificate is issued based on Evidence information provided by the certificate requestor to the issuing Certification Authority (CA). For instance, an individual seeking a publicly-trusted code signing certificate may be willing to disclose the details of the hardware where their code signing keys are stored (e.g., HSM model, patch level, etc.). However, they likely do not want this information to be publicly accessible. Applications that intend to publicly "broadcast" Evidence claims received from a third party via X.509 Certificates should define a Certificate Practices Statement that clearly specifies the circumstances under which the CA can include such data in the issued certificate. Note that the aforementioned consideration does not apply to cases where X.509 Certificates are explicitly designed as a security envelope for Evidence claims, such as in DICE .

Security Considerations The security considerations discussed in concerning the protection of conceptual messages are fully applicable. The following subsections provide further elaboration on these points, particularly in relation to Collection CMWs.

CMW Protection CMW Records, Tags, and Collections alone do not offer 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. 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) can be signed as described in . describes a number of methods that can be used to add cryptographic protection to CMW.

Using Collection CMWs for Evidence of Composite or Layered Devices When a Collection CMW is used to encapsulate Evidence for composite or layered attestation of a single device, all Evidence messages within the CMW MUST be cryptographically bound together to prevent an attacker from replacing Evidence from a compromised device with that from a non-compromised device. 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 manipulate the Collection's contents to deceive the Verifier into accepting bogus Evidence as genuine. Authenticity and integrity protection is expected to be provided by the underlying attestation technology. For example, key material used to sign/bind an entire Collection CMW should be an attestation key, handled as described in . The binding does not necessarily have to be a signature over the Collection CMW, it might also be achieved through identifiers, linking claims (e.g., nonces) across CMW collection items, signing or hashing between the members of the Collection. It is the responsibility of the Attester who creates the Collection CMW to ensure that the contents of the Collection are integrity-protected.

Integrating CMW into Protocols When CMW is integrated into some hosting protocol (for example, attested CSR or attested TLS ), it is up to that hosting protocol to describe how CMW is intended to be used and how it fits into the overall security model. Such an analysis should consider the types of conceptual messages allowed, including the permitted combinations, the protection requirements, the interface with the hosting protocol, and any other security-relevant aspect arising from the interaction between the CMW assembly and the hosting protocol.

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

CWT cmw Claim Registration IANA is requested to add a new cmw claim to the "CBOR Web Token (CWT) Claims" registry 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): , and of RFCthis

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 as follows:

• Claim Name: cmw
• Claim Description: A RATS Conceptual Message Wrapper
• Change Controller: IETF
• Specification Document(s): and of RFCthis

+jws Structured Syntax Suffix IANA is requested to register the +jws structured syntax suffix in the "Structured Syntax Suffixes" registry in the manner described in , which can be used to indicate that the media type is encoded as JSON Web Signature (JWS) .

Registry Contents

Name:

JSON Web Signature (JWS)

+suffix:

+jws

References:

Encoding Considerations:

binary; 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

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.

CBOR Tag Registration IANA is requested to add the following tag to the "CBOR Tags" registry.

CBOR Tag	Data Item	Semantics	Reference
CPA907	CBOR map, CBOR array, CBOR tag	RATS Conceptual Message Wrapper	, and of RFCthis

RATS Conceptual Message Wrapper (CMW) Indicators Registry This specification defines a new "RATS Conceptual Message Wrapper (CMW) Indicators" registry, with "IETF Review" policy (). The objective is to register CMW Indicator values for all RATS Conceptual Messages (see ). This registry is to be added to the Remote Attestation Procedures (RATS) registry group at . Indicator values should be added in ascending order, with no gaps between them. Acceptable values correspond to the RATS conceptual messages defined by the RATS architecture and any updates to it.

Structure of Entries Each entry in the registry must include:

Indicator value:

A number corresponding to the bit position in the ind bitmap ().

Conceptual Message name:

A text string describing the RATS conceptual message this indicator corresponds to.

Reference:

A reference to a document, if available, or the registrant.

The initial registrations for the registry are detailed in . CMW Indicators Registry Initial Contents

Indicator value	Conceptual Message name	Reference
0	Reference Values	of RFCthis
1	Endorsements	of RFCthis
2	Evidence	of RFCthis
3	Attestation Results	of RFCthis
4	Appraisal Policy	of RFCthis
5-31	Unassigned

Provisional Registration RFC Editor: Please remove this section before publication, as well as the reference to the provisional CMW Indicators registry. Before the creation of the registry by IANA, new codepoints can be added to the provisional CMW Indicators registry by following the documented procedure. will be regularly updated, prior to publication of this specification as an RFC, 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.

Media Types IANA is requested to add the following media types to the "Media Types" registry . CMW Media Types

Name	Template	Reference
cmw+cbor	application/cmw+cbor	, and of RFCthis
cmw+json	application/cmw+json	and of RFCthis
cmw+cose	application/cmw+cose	of RFCthis
cmw+jws	application/cmw+jws	of RFCthis

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:

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/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

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:

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

application/cmw+cose

Type name:

application

Subtype name:

cmw+cose

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.) Note that the cose-type parameter is explicitly not supported, as it is understood to be "cose-sign1".

Encoding considerations:

binary (CBOR)

Security considerations:

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

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:

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

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 : New CoAP Content Formats

Content-Type	Content Coding	ID	Reference
application/cmw+cbor	-	TBD1	, and of RFCthis
application/cmw+json	-	TBD2	and of RFCthis
application/cmw+cose	-	TBD3	of RFCthis
application/cmw+jws	-	TBD4	of RFCthis

If possible, TBD1, TBD2, TBD3 and TBD4 should be assigned in the 256..9999 range.

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 (), and
• The cmwc_t value is either a (non-relative) OID or an absolute URI.

New SMI Numbers Registrations IANA has assigned an object identifier (OID) for the CMW extension defined in in the "SMI Security for PKIX Certificate Extension" registry of the "SMI Numbers" registry group as follows: New CMW Extension OID

Decimal	Description	References
35	id-pe-cmw	of RFCthis

IANA is requested to assign an object identifier (OID) for the ASN.1 Module defined in in the "SMI Security for PKIX Module Identifier" registry of the "SMI Numbers" registry group: New ASN.1 Module OID

Decimal	Description	References
TBD	id-mod-cmw-extn	of RFCthis

References Normative References A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. The present document defines a number of control operators that were not yet ready at the time RFC 8610 was completed:.plus,.cat, and.det for the construction of constants;.abnf/.abnfb for including ABNF (RFC 5234 and RFC 7405) in CDDL specifications; and.feature for indicating the use of a non-basic feature in an instance. This document defines a stored ("file") format for Concise Binary Object Representation (CBOR) data items that is friendly to common systems that recognize file types, such as the Unix file(1) command. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. IANA IANA Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. International Telephone and Telegraph Consultative Committee In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. IANA IANA IANA IANA IANA IANA Informative References This document presents a framework to assist the writers of certificate policies or certification practice statements for participants within public key infrastructures, such as certification authorities, policy authorities, and communities of interest that wish to rely on certificates. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy or a certification practice statement. This document supersedes RFC 2527. The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative version. There are no bits- on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. 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. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. The Sensor Measurement Lists (SenML) media types support multiple types of values, from numbers to text strings and arbitrary binary Data Values. In order to facilitate processing of binary Data Values, this document specifies a pair of new SenML fields for indicating the content format of those binary Data Values, i.e., their Internet media type, including parameters as well as any content codings applied. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims. The payloads used in Remote ATtestation procedureS (RATS) may require an associated media type for their conveyance, for example, when the payloads are used in RESTful APIs. This memo defines media types to be used for Entity Attestation Tokens (EATs). Cisco Systems Fraunhofer SIT MIT Linaro Intel This document defines reusable Attestation Result information elements. When these elements are offered to Relying Parties as Evidence, different aspects of Attester trustworthiness can be evaluated. Additionally, where the Relying Party is interfacing with a heterogeneous mix of Attesting Environment and Verifier types, consistent policies can be applied to subsequent information exchange between each Attester and the Relying Party. This document also defines two serialisations of the proposed information model, utilising CBOR and JSON. This document defines the Unprotected CWT Claims Set (UCCS), a data format for representing a CBOR Web Token (CWT) Claims Set without protecting it by a signature, Message Authentication Code (MAC), or encryption. UCCS enables the use of CWT claims in environments where protection is provided by other means, such as secure communication channels or trusted execution environments. This specification defines a CBOR tag for UCCS and describes the UCCS format, its encoding, and its processing considerations. It also discusses security implications of using unprotected claims sets. Intuit Arm Limited Arm Limited Arm Limited Huawei Linaro The TLS handshake protocol allows authentication of one or both peers using static, long-term credentials. In some cases, it is also desirable to ensure that the peer runtime environment is in a secure state. Such an assurance can be achieved using attestation which is a process by which an entity produces evidence about itself that another party can use to appraise whether that entity is found in a secure state. This document describes a series of protocol extensions to the TLS 1.3 handshake that enables the binding of the TLS authentication key to a remote attestation session. This enables an entity capable of producing attestation evidence, such as a confidential workload running in a Trusted Execution Environment (TEE), or an IoT device that is trying to authenticate itself to a network access point, to present a more comprehensive set of security metrics to its peer. These extensions have been designed to allow the peers to use any attestation technology, in any remote attestation topology, and mutually. Linaro TU Dresden Nokia Intuit University of Applied Sciences Bonn-Rhein-Sieg Arm Limited This specification defines a method for two parties in a communication interaction to exchange Evidence and Attestation Results using exported authenticators, as defined in RFC 9261. Additionally, it introduces the cmw_attestation extension, which allows attestation credentials to be included directly in the Certificate message sent during the Exported Authenticator-based post-handshake authentication. The approach supports both the passport and background check models from the RATS architecture while ensuring that attestation remains bound to the underlying communication channel. Entrust Limited Siemens Fraunhofer SIT Intel Corporation A PKI end entity requesting a certificate from a Certification Authority (CA) may wish to offer trustworthy claims about the platform generating the certification request and the environment associated with the corresponding private key, such as whether the private key resides on a hardware security module. This specification defines an attribute and an extension that allow for conveyance of RATS conceptual messages (see Section 8 of [RFC9334], such as Evidence, Endorsements and Attestation Results, in Certificate Signing Requests (CSRs), such as PKCS#10 or Certificate Request Message Format (CRMF) payloads. This provides an elegant and automatable mechanism for transporting attestation data to a Certification Authority. Including Evidence, Endorsements and Attestation Results along with a CSR can help to improve the assessment of the security posture for the private key, and can help the Certification Authority to assess whether it satisfies the requested certificate profile. Fraunhofer SIT Linaro arm Independent Huawei Technologies Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether or not to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies the information elements for representing Endorsements and Reference Values in CBOR format. Trusted Computing Group Universität Bremen TZI CBOR-based protocols often make use of numbers allocated in a registry. During development of the protocols, those numbers may not yet be available. This impedes the generation of data models and examples that actually can be used by tools. This short draft proposes a common way to handle these situations, without any changes to existing tools. Also, in conjunction with the application-oriented EDN literal e'', a further reduction in editorial processing of CBOR examples around the time of approval can be achieved.

Registering and Using CMWs 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.

How To Create a CMW

Open Issues The list of currently open issues for this documents can be found at . RFC Editor: please remove before publication.

Acknowledgments The authors would like to thank Alexey Melnikov, Benjamin Schwartz, Brian Campbell, Carl Wallace, Carsten Bormann, Dave Thaler, Deb Cooley, , Michael B. Jones, Mike Ounsworth, Michael StJohns, Mohit Sethi, Paul Howard, Peter Yee, Russ Housley, Steven Bellock, Tim Bray, Tom Jones, and Usama Sardar 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 aims at superseding it by generalizing the allowed Evidence formats.

Contributors Security Theory LLC

lgl@securitytheory.com

Laurence made significant contributions to enhancing the security requirements and considerations for Collection CMWs.