<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.21 (Ruby 3.3.4) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-rats-uccs-12" number="9781" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true"version="3">version="3" xml:lang="en" updates="" obsoletes=""> <!--xml2rfc v2v3 conversion 3.23.0[rfced] We have the following questions regarding the title of this document. a) Note that we have updated the title as follows to expand abreviations upon first use per the RFC Style Guide (https://www.rfc-editor.org/styleguide/part2/). Original: A CBOR Tag for Unprotected CWT Claims Sets Current: A Concise Binary Object Representation (CBOR) Tag for Unprotected CBOR Web Token Claims Sets (UCCS) b) Should "UCCS" be written as "UCCSs" to indicate that it is a plural term? Note that this question also correlates to a separate abbreviation query later on. Perhaps: A Concise Binary Object Representation (CBOR) Tag for Unprotected CBOR Web Token Claims Sets (UCCSs) --> <front> <title abbrev="Unprotected CWT Claims Sets">ACBORConcise Binary Object Representation (CBOR) Tag for UnprotectedCWTCBOR Web Token ClaimsSets</title>Sets (UCCS)</title> <seriesInfoname="Internet-Draft" value="draft-ietf-rats-uccs-12"/>name="RFC" value="9781"/> <author initials="H." surname="Birkholz" fullname="Henk Birkholz"> <organization abbrev="Fraunhofer SIT">Fraunhofer SIT</organization> <address> <postal> <street>Rheinstrasse 75</street> <city>Darmstadt</city> <code>64295</code> <country>Germany</country> </postal> <email>henk.birkholz@ietf.contact</email> </address> </author> <author initials="J." surname="O'Donoghue" fullname="Jeremy O'Donoghue"> <organization abbrev="Qualcomm Technologies Inc.">Qualcomm Technologies Inc.</organization> <address> <postal> <street>279 Farnborough Road</street> <city>Farnborough</city> <code>GU14 7LS</code> <country>United Kingdom</country> </postal> <email>jodonogh@qti.qualcomm.com</email> </address> </author> <author initials="N." surname="Cam-Winget" fullname="Nancy Cam-Winget"> <organization>Cisco Systems</organization> <address> <postal> <street>3550 Cisco Way</street> <city>San Jose</city> <region>CA</region> <code>95134</code><country>USA</country><country>United States of America</country> </postal> <email>ncamwing@cisco.com</email> </address> </author> <author initials="C." surname="Bormann" fullname="Carsten Bormann"> <organization>Universität Bremen TZI</organization> <address> <postal> <street>Postfach 330440</street> <city>Bremen</city> <code>D-28359</code> <country>Germany</country> </postal> <phone>+49-421-218-63921</phone> <email>cabo@tzi.org</email> </address> </author> <dateyear="2024" month="November" day="03"/> <area>Security</area> <workgroup>RATS Working Group</workgroup> <keyword>Internet-Draft</keyword>year="2025" month="April"/> <area>SEC</area> <workgroup>rats</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <abstract><?line 91?><t>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 codeMessage 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 processingconsiderations, andconsiderations. It also discusses security implications of using unprotected claims sets.</t><t><cref anchor="status">(This editors' note will be removed by the RFC editor:)<br/> The present revision (–12) contains remaining document changes based on feedback from the IESG evaluation and has been submitted as input to IETF 121.</cref></t></abstract><note removeInRFC="true"> <name>About This Document</name> <t> Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-rats-uccs/"/>. </t> <t> Discussion of this document takes place on the Remote ATtestation procedureS (rats) Working Group mailing list (<eref target="mailto:rats@ietf.org"/>), which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/rats/"/>. Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/rats/"/>. </t> <t>Source for this draft and an issue tracker can be found at <eref target="https://github.com/ietf-rats-wg/draft-ietf-rats-uccs"/>.</t> </note></front> <middle><?line 110?><section anchor="introduction"> <name>Introduction</name> <t>A CBOR Web Token (CWT) as specified by <xref target="RFC8392"/> is always wrapped in a CBOR Object Signing and Encryption(COSE,(COSE) envelope <xreftarget="STD96"/>) envelope.target="STD96"/>. Among other things, COSE provides-- among other things --end-to-end data origin authentication and integrity protection employed byRFC 8392<xref target="RFC8392"/> as well as optional encryption for CWTs. Under the right circumstances (<xref target="secchan"/>),though,a signature providing proof for authenticity and integrity can be provided through the transfer protocol and thus omitted from the information in a CWT without compromising the intended goal of authenticity and integrity. In other words, if communicating parties have a preexisting security association, they can reuse it to provide authenticity and integrity for their messages, enabling the basic principle of using resources parsimoniously. Specifically, if a mutually secured channel is established between two remote peers, and if that secure channel provides the required properties (as discussed below), it is possible to omit the protection provided by COSE, creating a use case for unprotected CWT Claims Sets. Similarly, if there is one-way authentication, the party that did not authenticate may be in a position to send authentication information through this channel that allows the already authenticated party to authenticate the other party; this effectively turns the channel into a mutually secured channel.</t> <t>This specification allocates a CBOR tag to mark Unprotected CWT Claims Sets (UCCS) as such and discusses conditions for its proper use in the scope of Remote Attestation Procedures (RATS <xref target="RFC9334"/>) for the conveyance of RATS Conceptual Messages.</t> <t>This specification does not change <xref target="RFC8392"/>:An actual RFC 8392A CWT as defined by <xref target="RFC8392"/> does not make use of the tag allocated here; the UCCS tag is an alternative to using COSE protection and a CWT tag. <!-- [rfced] In the following, does use of "can be acceptable" mean that there are cases where it is not acceptable? If not, may we update as follows for precision and readability? Current: Consequently, within the well-defined scope of a secure channel, it can be acceptable and economic to use the contents of a CWT without its COSE container and tag it with a UCCS CBOR tag for further processing within that scope - or to use the contents of a UCCS CBOR tag for building a CWT to be signed by some entity that can vouch for those contents. Perhaps: Consequently, within the well-defined scope of a secure channel, it is acceptable and economic to use the contents of a CWT without its COSE container and tag it with a UCCS CBOR tag for further processing within that scope. It is also acceptable to use the contents of a UCCS CBOR tag for building a CWT to be signed by some entity that can vouch for those contents. --> Consequently, within the well-defined scope of a secure channel, it can be acceptable and economic to use the contents of a CWT without its COSE container and tag it with a UCCS CBOR tag for further processing within that scope -- or to use the contents of a UCCS CBOR tag for building a CWT to be signed by some entity that can vouch for those contents.</t> <section anchor="terminology"> <name>Terminology</name> <t>The term Claim is used as in <xref target="RFC7519"/>.</t> <t>The terms Claim Key, Claim Value, and CWT Claims Set are used as in <xref target="RFC8392"/>.</t> <t>The terms Attester, Attesting Environment, Evidence, Relying Party and Verifier are used as in <xref target="RFC9334"/>.</t><dl><dl spacing="normal"> <dt>UCCS:</dt><dd> <t>Unprotected<dd><t>Unprotected CWT Claims Set(s); CBOR map(s) of Claims as defined by the CWT Claims Registry that are composed of pairs of Claim Keys and ClaimValues.</t> </dd>Values.</t></dd> <dt>Secure Channel:</dt><dd> <t><xref<dd><t><xref target="NIST-SP800-90Ar1"/> defines a Secure Channel asfollows: </t> <aside>follows:</t> <!-- [Note to reference reviwer and PE] This really is a block quote, but RFCXMLv3 doesn't allow that --><t>"A<!-- Quoted text from [NIST-SP800-90Ar1] is correct.--> <t indent="3">"A path for transferring data between two entities or components that ensures confidentiality, integrity and replay protection, as well as mutual authentication between the entities or components. The secure channel may be provided using approved cryptographic, physical or procedural methods, or a combination thereof."</t></aside><t>For the purposes of the present document, we focus on a protected communication channel used for conveyance that can ensure the same qualities as a CWT without havingtheCOSE protectionavailable:available, which includes mutual authentication, integrity protection, and confidentiality. (Replay protection can be added by including a nonce claim such as Nonce (claim 10 <xref target="IANA.cwt"/>).) Examples include conveyance via PCIe (Peripheral Component InterconnectExpress)Express), IDE (Integrity and DataEncryption)Encryption), or a TLS tunnel.</t> </dd> </dl> <t>All terms referenced or defined in this section are capitalized in the remainder of this document.</t><t>The<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xreftarget="BCP14"/> (<xref target="RFC2119"/>) (<xref target="RFC8174"/>)target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t> <?line -18?>here. </t> </section> <section anchor="structure-of-this-document"> <name>Structure ofthis document</name>This Document</name> <t><xref target="usage"/> briefly discusses use cases for UCCS. <xref target="secchan"/> addresses general characteristics of secure channels, followed by a specific discussion of using them in the context of RATS Conceptual Message Conveyance in <xref target="uccs-rats"/>, andfinally somemore forward-looking considerations for using UCCS in other RATS contexts are discussed in <xref target="other-rats"/>.Conventional sections (<xrefThis is followed by the <xref format="title" target="iana"/>, <xref format="title" target="seccons"/>, <xref format="title" target="sec-normative-references"/>, and <xref format="title"target="sec-informative-references"/>) follow.target="sec-informative-references"/>. The normative <xref target="cddl"/> provides a formal definition of the structure ofUCCSUCCS, as no formal definition of CWT Claims Sets was provided in <xref target="RFC8392"/>. <!-- [rfced] We note that UJCS has not appeared in an RFC previously. Please review the following sentence and let us know how the text may be updated, as [RFC7519] defines the JSON Web Token (JWT), but UJCS is not mentioned. RFC 7519 does use the term "Unsecured JWT". Are these the same? Current: This employs the Concise Data Definition Language (CDDL) [RFC8610], using its ability to also describe the structurally similar Unprotected JWT Claims Sets [RFC7519] (UJCS) in the same definition. --> This employs the Concise Data Definition Language (CDDL) <xref target="RFC8610"/>, using its ability to also describe the structurally similar Unprotected JWT Claims Sets (UJCS) <xref target="RFC7519"/>(UJCS)in the same definition. <xref target="example"/> provides an (informative) example for CBOR-Tagged UCCS. The normative <xref target="eat"/> provides CDDL rules that add UCCS-format tokens to Entity Attestation Tokens(EATs, see(EATs) <xreftarget="I-D.ietf-rats-eat"/>)target="RFC9711"/> using its predefined extension points.</t> </section> </section> <section anchor="usage"> <name>Deployment and Usage of UCCS</name> <t>Usage scenarios involving the conveyance ofClaims,Claims (RATS, inparticular RATS,particular) require a standardized data definition and encoding format that can be transferred and transported using different communication channels. As these are Claims, the Claims Sets defined in <xref target="RFC8392"/> are a suitable format. However, the way these Claims are secured depends on the deployment, the security capabilities of the device, as well as their software stack. For example, a Claim may be securely stored and conveyed using a device's Trusted Execution Environment(TEE, see(TEE) <xreftarget="RFC9397"/>)target="RFC9397"/> or a Trusted Platform Module(TPM, see(TPM) <xreftarget="TPM2"/>).target="TPM2"/>. Especially in some resource-constrained environments, the same process that provides the secure communication transport is also the delegate to compose the Claim to be conveyed. Whether it is a transfer or transport, a Secure Channel is presumed to be used for conveying such UCCS. The following sections elaborate on Secure Channel characteristics in general and further describe RATS usage scenarios and corresponding requirements for UCCS deployment.</t> </section> <section anchor="secchan"> <name>Characteristics of a Secure Channel</name> <t>A Secure Channel for the conveyance of UCCS needs to provide the security properties that would otherwise be provided by COSE for a CWT. In this regard, UCCS is similar in security considerations to JWTs <xref target="BCP225"/> using the algorithm "none". Section <xref target="RFC8725" section="3.2" sectionFormat="bare"/> of RFC 8725 <xref target="BCP225"/> states:</t> <blockquote> <t>[...] if a JWT is cryptographically protected end-to-end by a transport layer, such as TLS using cryptographically current algorithms, there may be no need to apply another layer of cryptographic protections to the JWT. In such cases, the use of the "none" algorithm can be perfectly acceptable.</t> </blockquote> <t>The security considerations discussed, e.g., in Sections <xref target="RFC8725" section="2.1" sectionFormat="bare"/>, <xref target="RFC8725" section="3.1" sectionFormat="bare"/>, and <xref target="RFC8725" section="3.2" sectionFormat="bare"/> of RFC 8725 <xref target="BCP225"/> apply in an analogous way to the use of UCCS as elaborated on in this document. In particular, the need to "Use Appropriate Algorithms" (Section <xref target="RFC8725" section="3.2" sectionFormat="bare"/> of RFC 8725 <xref target="BCP225"/>) includes choosing appropriate cryptographic algorithms for setting up and protecting the Secure Channel. For instance, their cryptographic strength should be at least as strong as any cryptographic keys the Secure Channel will be used for to protect in transport. <xref target="tab-algsec"/> in <xref target="algsec"/> provides references to some more security considerations for specific cryptography choices that are discussed in the COSE initial algorithms specification <xref target="RFC9053"/>.</t> <t>Secure Channels are often set up in a handshake protocol that mutually derives a session key, where the handshake protocol establishes the (identity and thus) authenticity of one or both ends of the communication. The session key can then be used to provide confidentiality and integrity of the transfer of information inside the Secure Channel. (Where the handshake did not provide a mutually secure channel, further authentication information can be conveyed by the party not yet authenticated, leading to a mutually secured channel.) A well-known example of a such a Secure Channel setup protocol is the TLS <xref target="RFC8446"/> handshake; the TLS record protocol can then be used for secure conveyance.</t> <t>As UCCS were initially created for use in RATS Secure Channels, the following section provides a discussion of their use in these channels. Where other environments are intended to be used to convey UCCS, similar considerations need to be documented before UCCS can be used.</t> </section> <section anchor="uccs-rats"> <name>UCCS in RATS Conceptual Message Conveyance</name> <t>This section describes a detailed usage scenario for UCCS in the context of RATS in conjunction with its attendant security requirements. The use of UCCS tagCPA601601 outside of the RATS context <bcp14>MUST</bcp14> come with additional instruction leaflets and security considerations.</t> <t>For the purposes of this section, any RATS role can be the sender or the receiver of the UCCS.</t> <t>Secure Channels can be transient in nature. For the purposes of this specification, the mechanisms used to establish a Secure Channel are out of scope.</t> <t>In the scope of RATS Claims, the receiver <bcp14>MUST</bcp14> authenticate the sender as part of the establishment of the Secure Channel. Furthermore, the channel <bcp14>MUST</bcp14> provide integrity of the communication between the communicating RATS roles. For data confidentiality <xref target="RFC4949"/>, the receiving side <bcp14>MUST</bcp14> be authenticated aswell; thiswell. This is achieved if the sender and receiver mutually authenticate when establishing the Secure Channel. The quality of the receiver's authentication and authorization will influence whether the sender can disclose the UCCS.</t> <t>The extent to which a Secure Channel can provide assurances that UCCS originate from a trustworthy Attesting Environment depends on the characteristics of both the cryptographic mechanisms used to establish the channel and the characteristics of the Attesting Environment itself. <!-- [rfced] To clarify, does "it" refer to the Attesting Enviornment? Original: The assurance provided to a Relying Party depends on the authenticity and integrity properties of the Secure Channel used for conveying the UCCS to it. Perhaps: The assurance provided to a Relying Party depends on the authenticity and integrity properties of the Secure Channel used for conveying the UCCS to the Attesting Enviornment. --> The assurance provided to a Relying Party depends on the authenticity and integrity properties of the Secure Channel used for conveying the UCCS to it.</t> <t>Ultimately, it is up to the receiver's policy to determine whether to accept a UCCS from the sender and to determine the type of Secure Channel it must negotiate. While the security considerations of the cryptographic algorithms used are similar to COSE, the considerations of the Secure Channel should also adhere to the policy configured at each of end of the Secure Channel. However, the policy controls and definitions are out of scope for this document.</t> <t>Where an Attesting Environment serves as an endpoint of a Secure Channel used to convey a UCCS, the security assurance required of that Attesting Environment by a Relying Party generally calls for the Attesting Environment to be implemented using techniques designed to provide enhanced protection from an attacker wishing to tamper with or forge a UCCS originating from that Attesting Environment. A possible approach might be to implement the Attesting Environment in a hardenedenvironmentenvironment, such as a TEE <xref target="RFC9397"/> or a TPM <xref target="TPM2"/>.</t> <!-- [rfced] Related to our earlier question about whether UCCS should be UCCSs in the plural form, please review the use of UCCS in the text below. Is it intended to be singular or plural? For example, "emerge" indicates plural, but the text also refers to "the UCCS" (singular) and "which now are" (plural). We will review each use of UCCS more closely once we better understand the intent here. Original: When UCCS emerge from the Secure Channel and into the receiver, the security properties of the secure channel no longer protect the UCCS, which now are subject to the same security properties as any other unprotected data in the Verifier environment. If the receiver subsequently forwards UCCS, they are treated as though they originated within the receiver. --> <t>When UCCS emerge from the Secure Channel and into the receiver, the security properties of the secure channel no longer protect the UCCS, which now are subject to the same security properties as any other unprotected data in the Verifier environment. If the receiver subsequently forwards UCCS, they are treated as though they originated within the receiver.</t> <t>The Secure Channel context does not govern fully formed CWTs in the same way it governs UCCS. As withEntity Attestation Tokens (EATs, seeEATs (see <xreftarget="I-D.ietf-rats-eat"/>)target="RFC9711"/>) nested in other EATs (Section <xreftarget="I-D.ietf-rats-eat"target="RFC9711" section="4.2.18.3" sectionFormat="bare">Nested Tokens</xref> of <xreftarget="I-D.ietf-rats-eat"/>),target="RFC9711"/>), the Secure Channel does not endorse fully formed CWTs transferred through it. Effectively, the COSE envelope of a CWT (or a nested EAT) shields the CWT Claims Set from the endorsement of the secure channel. (Note that an EAT might add a nested UCCS Claim, and this statement does not apply to UCCS nested intoUCCS,UCCS; it only applies to fully formed CWTs.)</t> </section> <section anchor="other-rats"> <name>Considerations for Using UCCS in Other RATS Contexts</name> <t>This section discusses two additional usage scenarios for UCCS in the context of RATS.</t> <section anchor="delegated-attestation"> <name>Delegated Attestation</name> <t>Another usage scenario is that of a sub-Attester that has no signing keys (for example, to keep the implementation complexity to a minimum) and has a Secure Channel, such as local inter-process communication, to interact with a lead Attester (see "Composite Device", <xref section="3.3" sectionFormat="of" target="RFC9334"/>). The sub-Attester produces a UCCS with the required CWT Claims Set and sends the UCCS through the Secure Channel to the lead Attester. The lead Attester then computes a cryptographic hash of the UCCS and protects that hash using its signing key for Evidence, for example, using a Detached-Submodule-Digest or Detached EAT Bundle (<xref section="5" sectionFormat="of"target="I-D.ietf-rats-eat"/>).</t>target="RFC9711"/>).</t> </section> <section anchor="privacy-preservation"> <name>Privacy Preservation</name> <t>A Secure Channelwhichthat preserves the privacy of the Attester may provide security properties equivalent to COSE, but only inside the life-span of the session established. In general, when aprivacy preservingprivacy-preserving Secure Channel is employedfor conveyingto convey a conceptual message, the receiver cannot correlate the message with the senders of other received UCCS messages beyond the information the Secure Channel authentication provides.</t> <t>An Attester must consider whether any UCCS it returns over aprivacy preservingprivacy-preserving Secure Channel compromises the privacy in unacceptable ways. As an example, the use of the EAT UEID Claim (<xref section="4.2.1" sectionFormat="of"target="I-D.ietf-rats-eat"/>)target="RFC9711"/>) in UCCS over aprivacy preservingprivacy-preserving Secure Channel allows a Verifier to correlate UCCS from a single Attesting Environment across many Secure Channel sessions. This may be acceptable in someuse-casesuse cases (e.g., if the Attesting Environment is a physical sensor in a factory) and unacceptable in others (e.g., if the Attesting Environment is a user device belonging to a child).</t> </section> </section> <section anchor="iana"> <name>IANA Considerations</name> <section anchor="cbor-tag-registration"> <name>CBOR Tagregistration</name>Registration</name> <t>In theCBOR Tags"CBOR Tags" registry <xref target="IANA.cbor-tags"/> as defined in Section <xref target="RFC8949" section="9.2" sectionFormat="bare"/> of RFC 8949 <xref target="STD94"/>, IANAis requested to allocatehas allocated the tag in <xref target="tab-tag-values"/> from the Specification Required space (1+2 size), with the present document as the specification reference.</t> <table anchor="tab-tag-values"> <name>Values for Tags</name> <thead> <tr> <th align="right">Tag</th> <th align="left">Data Item</th> <th align="left">Semantics</th> </tr> </thead> <tbody> <tr> <tdalign="right">CPA601</td>align="right">601</td> <td align="left">map (Claims-Set as per <xref target="cddl"/> of[RFCthis])</td>[RFC9781])</td> <td align="left">Unprotected CWT Claims Set[RFCthis]</td>[RFC9781]</td> </tr> </tbody> </table><t><cref anchor="cpa">RFC-Editor: This document uses the CPA (code point allocation) convention described in [I-D.bormann-cbor-draft-numbers]. For each usage of the term "CPA", please remove the prefix "CPA" from the indicated value and replace the residue with the value assigned by IANA; perform an analogous substitution for all other occurrences of the prefix "CPA" in the document. Finally, please remove this note.</cref></t></section> <section anchor="media-type"> <name>Media-Type application/uccs+cbor Registration</name> <t>IANAis requested to addhas added the followingMedia-Typeto the "Media Types" registry <xref target="IANA.media-types"/>.</t> <table anchor="new-media-type"> <name>Media Type Registration</name> <thead> <tr> <th align="left">Name</th> <th align="left">Template</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">uccs+cbor</td> <td align="left">application/uccs+cbor</td> <td align="left"> <xref target="media-type"/> ofRFCthis</td>RFC 9781</td> </tr> </tbody> </table> <dlspacing="compact">newline="false" spacing="normal"> <dt>Type name:</dt><dd> <t>application</t> </dd><dd>application</dd> <dt>Subtype name:</dt><dd> <t>uccs+cbor</t> </dd><dd>uccs+cbor</dd> <dt>Required parameters:</dt><dd> <t>n/a</t> </dd><dd>n/a</dd> <dt>Optional parameters:</dt><dd> <t>n/a</t> </dd><dd>n/a</dd> <dt>Encoding considerations:</dt><dd> <t>binary<dd>binary (CBOR dataitem)</t> </dd>item)</dd> <dt>Security considerations:</dt><dd> <t><xref<dd><xref target="seccons"/> ofRFCthis</t> </dd>RFC 9781</dd> <dt>Interoperability considerations:</dt><dd> <t>none</t> </dd><dd>none</dd> <dt>Published specification:</dt><dd> <t>RFCthis</t> </dd><dd>RFC 9781</dd> <dt>Applications that use this media type:</dt><dd> <t>Applications<dd>Applications that transfer Unprotected CWT Claims Set(s) (UCCS) over SecureChannels</t> </dd>Channels</dd> <dt>Fragment identifier considerations:</dt><dd> <t>The<dd>The syntax and semantics of fragment identifiers is as specified for "application/cbor". (At publication of this document, there is no fragment identification syntax defined for"application/cbor".)</t> </dd>"application/cbor".)</dd> <dt>Additional information:</dt><dd> <dl><dd><t><br/></t> <dl spacing="compact" newline="false"> <dt>Deprecated alias names for this type:</dt><dd> <t>N/A</t> </dd><dd>N/A</dd> <dt>Magic number(s):</dt><dd> <t>N/A</t> </dd><dd>N/A</dd> <dt>File extension(s):</dt><dd> <t>.uccs</t> </dd><dd>.uccs</dd> <dt>Macintosh file type code(s):</dt><dd> <t>N/A</t> </dd><dd>N/A</dd> </dl> </dd> <dt>Person and email address to contact for further information:</dt><dd> <t>RATS<dd>RATS WG mailing list(rats@ietf.org)</t> </dd>(rats@ietf.org)</dd> <dt>Intended usage:</dt><dd> <t>COMMON</t> </dd><dd>COMMON</dd> <dt>Restrictions on usage:</dt><dd> <t>none</t> </dd><dd>none</dd> <dt>Author/Change controller:</dt><dd> <t>IETF</t> </dd><dd>IETF</dd> </dl> </section> <section anchor="media-type-json"> <name>Media-Type application/ujcs+json Registration</name> <t>IANAis requested to addhas added the followingMedia-Typeto the "Media Types" registry <xref target="IANA.media-types"/>.</t> <table anchor="new-media-type-json"> <name>JSON Media Type Registration</name> <thead> <tr> <th align="left">Name</th> <th align="left">Template</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">ujcs+json</td> <td align="left">application/ujcs+json</td> <td align="left"> <xref target="media-type-json"/> ofRFCthis</td>RFC 9781</td> </tr> </tbody> </table> <dlspacing="compact">spacing="normal" newline="false"> <dt>Type name:</dt><dd> <t>application</t> </dd><dd>application</dd> <dt>Subtype name:</dt><dd> <t>ujcs+json</t> </dd><dd>ujcs+json</dd> <dt>Required parameters:</dt><dd> <t>n/a</t> </dd><dd>n/a</dd> <dt>Optional parameters:</dt><dd> <t>n/a</t> </dd><dd>n/a</dd> <dt>Encoding considerations:</dt><dd> <t>binary (UTF-8)</t> </dd><dd>binary (UTF-8)</dd> <dt>Security considerations:</dt><dd> <t><xref<dd><xref target="seccons"/> ofRFCthis</t> </dd>RFC 9781</dd> <dt>Interoperability considerations:</dt><dd> <t>none</t> </dd><dd>none</dd> <dt>Published specification:</dt><dd> <t>RFCthis</t> </dd><dd>RFC 9781</dd> <dt>Applications that use this media type:</dt><dd> <t>Applications<dd>Applications that transfer Unprotected JWT Claims Set(s) (UJCS) over SecureChannels</t> </dd>Channels</dd> <dt>Fragment identifier considerations:</dt><dd> <t>The<dd>The syntax and semantics of fragment identifiers is as specified for "application/json". (At publication of this document, there is no fragment identification syntax defined for"application/json".)</t> </dd>"application/json".)</dd> <dt>Additional information:</dt><dd> <dl><dd><t><br/></t> <dl spacing="compact" newline="false"> <dt>Deprecated alias names for this type:</dt><dd> <t>N/A</t> </dd><dd>N/A</dd> <dt>Magic number(s):</dt><dd> <t>N/A</t> </dd><dd>N/A</dd> <dt>File extension(s):</dt><dd> <t>.ujcs</t> </dd><dd>.ujcs</dd> <dt>Macintosh file type code(s):</dt><dd> <t>N/A</t> </dd><dd>N/A</dd> </dl> </dd> <dt>Person and email address to contact for further information:</dt><dd> <t>RATS<dd>RATS WG mailing list(rats@ietf.org)</t> </dd>(rats@ietf.org)</dd> <dt>Intended usage:</dt><dd> <t>COMMON</t> </dd><dd>COMMON</dd> <dt>Restrictions on usage:</dt><dd> <t>none</t> </dd><dd>none</dd> <dt>Author/Change controller:</dt><dd> <t>IETF</t> </dd><dd>IETF</dd> </dl> </section> <section anchor="ct"> <name>Content-Formatregistration</name>Registration</name> <t>IANAis requested to register a Content-Format numberhas registered the following in the "CoAP Content-Formats"subregistry,registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group <xreftarget="IANA.core-parameters"/>, as follows:</t>target="IANA.core-parameters"/>.</t> <table anchor="content-format-reg"> <name>Content-Format Registration</name> <thead> <tr> <th align="left">Content Type</th> <th align="left">Content Coding</th> <th align="left">ID</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">application/uccs+cbor</td> <td align="left">-</td> <tdalign="left">TBD601</td>align="left">601</td> <td align="left"> <xref target="ct"/> ofRFCthis</td>RFC 9781</td> </tr> </tbody> </table><t><cref anchor="tbd">RFC editor: please replace TBD601 by the number actually assigned by IANA (601 is suggested).</cref></t></section> </section> <section anchor="seccons"> <name>Security Considerations</name> <t>The security considerations of <xref target="STD94"/> apply. The security considerations of <xref target="RFC8392"/> need to be applied analogously, replacing the function of COSE with that of the Secure Channel; inparticularparticular, "it is not only important to protect the CWT in transit but also to ensure that the recipient can authenticate the party that assembled the claims and created the CWT".</t> <t><xref target="secchan"/> discusses security considerations for SecureChannels,Channels in which UCCS might be used. This document provides the CBOR tag definition for UCCS and a discussion on security consideration for the use of UCCS in RATS. Uses of UCCS outside the scope of RATS are not covered by this document. The UCCS specification -- and the use of the UCCS CBOR tag, correspondingly -- is not intended for use in a scope where a scope-specific security consideration discussion has not been conducted,vettedvetted, and approved for that use. In order to be able to use the UCCS CBOR tag in another such scope, the secure channel and/or the application protocol (e.g., TLS and the protocol identified by ALPN) <bcp14>MUST</bcp14> specify the roles of the endpoints in a fashion that the security properties of conveying UCCS via a Secure Channel between the roles are well-defined.</t> <section anchor="general-considerations"> <name>General Considerations</name> <t>Implementations of Secure Channels are often separate from the application logic that has security requirements on them. Similar security considerations to those described in <xref target="STD96"/> for obtaining the required levels of assurance include:</t> <ul spacing="normal"> <li> <t>Implementations need to provide sufficient protection for private or secret key material used to establish or protect the Secure Channel.</t> </li> <li> <t>Using a key for more than one algorithm can leak information about the key and is not recommended.</t> </li> <li> <t>An algorithm used to establish or protect the Secure Channel may have limits on the number of times that a key can be used without leaking information about the key.</t> </li> <li> <t>Evidence in a UCCS conveyed in a Secure Channel generally cannot be used to support trust in the credentials that were used to establish that secure channel, as this would create a circular dependency.</t> </li> </ul> <t>The Verifier needs to ensure that the management of key material used to establish or protect the Secure Channel is acceptable. This may include factors such as:</t> <ul spacing="normal"> <li> <t>Ensuring that any permissions associated with key ownership are respected in the establishment of the Secure Channel.</t> </li> <li> <t>Using cryptographic algorithms appropriately.</t> </li> <li> <t>Using key material in accordance with any usage restrictions such as freshness or algorithm restrictions.</t> </li> <li> <t>Ensuring that appropriate protections are in place to address potential traffic analysis attacks.</t> </li> </ul> </section> <section anchor="algsec"><name>Algorithm-specific<name>Algorithm-Specific Security Considerations</name> <t><xref target="tab-algsec"/> provides references to some security considerations of specific cryptography choices that are discussed in <xref target="RFC9053"/>.</t> <table anchor="tab-algsec"><name>Algorithm-specific<name>Algorithm-Specific Security Considerations</name> <thead> <tr> <th align="left">Algorithm</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">AES-CBC-MAC</td> <td align="left"> <xref section="3.2.1" sectionFormat="of" target="RFC9053"/></td> </tr> <tr> <td align="left">AES-GCM</td> <td align="left"> <xref section="4.1.1" sectionFormat="of" target="RFC9053"/></td> </tr> <tr> <td align="left">AES-CCM</td> <td align="left"> <xref section="4.2.1" sectionFormat="of" target="RFC9053"/></td> </tr> <tr> <td align="left">ChaCha20/Poly1305</td> <td align="left"> <xref section="4.3.1" sectionFormat="of" target="RFC9053"/></td> </tr> </tbody> </table> </section> </section> </middle> <back> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><referencegroup anchor="STD94" target="https://www.rfc-editor.org/info/std94"> <reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rfc8949"> <front> <title>Concise Binary Object Representation (CBOR)</title> <author fullname="C. Bormann" initials="C." surname="Bormann"/> <author fullname="P. Hoffman" initials="P." surname="Hoffman"/> <date month="December" year="2020"/> <abstract> <t>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.</t> <t>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.</t> </abstract> </front> <seriesInfo name="STD" value="94"/> <seriesInfo name="RFC" value="8949"/> <seriesInfo name="DOI" value="10.17487/RFC8949"/> </reference> </referencegroup> <reference anchor="RFC7519"> <front> <title>JSON Web Token (JWT)</title> <author fullname="M. Jones" initials="M." surname="Jones"/> <author fullname="J. Bradley" initials="J." surname="Bradley"/> <author fullname="N. Sakimura" initials="N." surname="Sakimura"/> <date month="May" year="2015"/> <abstract> <t>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.</t> </abstract> </front> <seriesInfo name="RFC" value="7519"/> <seriesInfo name="DOI" value="10.17487/RFC7519"/> </reference> <referencegroup anchor="BCP225" target="https://www.rfc-editor.org/info/bcp225"> <reference anchor="RFC8725" target="https://www.rfc-editor.org/info/rfc8725"> <front> <title>JSON Web Token Best Current Practices</title> <author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/> <author fullname="D. Hardt" initials="D." surname="Hardt"/> <author fullname="M. Jones" initials="M." surname="Jones"/> <date month="February" year="2020"/> <abstract> <t>JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs.</t> </abstract> </front> <seriesInfo name="BCP" value="225"/> <seriesInfo name="RFC" value="8725"/> <seriesInfo name="DOI" value="10.17487/RFC8725"/> </reference> </referencegroup> <reference anchor="RFC8392"> <front> <title>CBOR Web Token (CWT)</title> <author fullname="M. Jones" initials="M." surname="Jones"/> <author fullname="E. Wahlstroem" initials="E." surname="Wahlstroem"/> <author fullname="S. Erdtman" initials="S." surname="Erdtman"/> <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/> <date month="May" year="2018"/> <abstract> <t>CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON.</t> </abstract> </front> <seriesInfo name="RFC" value="8392"/> <seriesInfo name="DOI" value="10.17487/RFC8392"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.94.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.225.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8392.xml"/> <reference anchor="IANA.cbor-tags" target="https://www.iana.org/assignments/cbor-tags"> <front> <title>Concise Binary Object Representation (CBOR) Tags</title> <author> <organization>IANA</organization> </author> </front> </reference> <reference anchor="IANA.cwt" target="https://www.iana.org/assignments/cwt"> <front> <title>CBOR Web Token (CWT) Claims</title> <author> <organization>IANA</organization> </author> </front> </reference><reference anchor="RFC8610"> <front> <title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title> <author fullname="H. Birkholz" initials="H." surname="Birkholz"/> <author fullname="C. Vigano" initials="C." surname="Vigano"/> <author fullname="C. Bormann" initials="C." surname="Bormann"/> <date month="June" year="2019"/> <abstract> <t>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.</t> </abstract> </front> <seriesInfo name="RFC" value="8610"/> <seriesInfo name="DOI" value="10.17487/RFC8610"/> </reference> <reference anchor="RFC9165"> <front> <title>Additional Control Operators for the Concise Data Definition Language (CDDL)</title> <author fullname="C. Bormann" initials="C." surname="Bormann"/> <date month="December" year="2021"/> <abstract> <t>The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point.</t> <t>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.</t> </abstract> </front> <seriesInfo name="RFC" value="9165"/> <seriesInfo name="DOI" value="10.17487/RFC9165"/> </reference> <referencegroup anchor="BCP14" target="https://www.rfc-editor.org/info/bcp14"> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t>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.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <date month="May" year="2017"/> <abstract> <t>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.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference> </referencegroup><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8610.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9165.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name> <reference anchor="IANA.media-types" target="https://www.iana.org/assignments/media-types"> <front> <title>Media Types</title> <author> <organization>IANA</organization> </author> </front> </reference> <reference anchor="IANA.core-parameters" target="https://www.iana.org/assignments/core-parameters"> <front> <title>Constrained RESTful Environments (CoRE) Parameters</title> <author> <organization>IANA</organization> </author> </front> </reference><reference anchor="RFC4949"> <front> <title>Internet Security Glossary, Version 2</title> <author fullname="R. Shirey" initials="R." surname="Shirey"/> <date month="August" year="2007"/> <abstract> <t>This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4949.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9334.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9397.xml"/> <!-- [rfced] We found thecomprehensibility of written material that is generated infollowing URL for theInternet Standards Process (RFC 2026). The recommendations followreference below: https://trustedcomputinggroup.org/resource/tpm-library-specification/. Should this URL be added to theprinciplesreference? Note thatsuch writing should (a) use the same term or definition whenever the same conceptthere ismentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favoraparticular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.</t> </abstract> </front> <seriesInfo name="FYI" value="36"/> <seriesInfo name="RFC" value="4949"/> <seriesInfo name="DOI" value="10.17487/RFC4949"/> </reference> <reference anchor="RFC8446"> <front> <title>The Transport Layer Security (TLS) Protocol Version 1.3</title> <author fullname="E. Rescorla" initials="E." surname="Rescorla"/> <date month="August" year="2018"/> <abstract> <t>This document specifiesmore recent version1.3ofthe Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the InternetTPM 2.0 released ina wayMarch 2024 that isdesigned to prevent eavesdropping, tampering, and message forgery.</t> <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This documentalsospecifies new requirements for TLS 1.2 implementations.</t> </abstract> </front> <seriesInfo name="RFC" value="8446"/> <seriesInfo name="DOI" value="10.17487/RFC8446"/> </reference> <reference anchor="RFC9334"> <front> <title>Remote ATtestation procedureS (RATS) Architecture</title> <author fullname="H. Birkholz" initials="H." surname="Birkholz"/> <author fullname="D. Thaler" initials="D." surname="Thaler"/> <author fullname="M. Richardson" initials="M." surname="Richardson"/> <author fullname="N. Smith" initials="N." surname="Smith"/> <author fullname="W. Pan" initials="W." surname="Pan"/> <date month="January" year="2023"/> <abstract> <t>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 throughavailable at this URL. Should theprocess of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures,reference be udpated to thecontent of Claims, and protocols.</t> </abstract> </front> <seriesInfo name="RFC" value="9334"/> <seriesInfo name="DOI" value="10.17487/RFC9334"/> </reference>most current version? Current: [TPM2] Trusted Computing Group, "Trusted Platform Module Library Specification", Family "2.0", Level 00, Revision 01.59, 2019. --> <referenceanchor="RFC9397">anchor="TPM2"> <front> <title>TrustedExecution Environment Provisioning (TEEP) Architecture</title> <author fullname="M. Pei" initials="M." surname="Pei"/> <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/> <author fullname="D. Thaler" initials="D." surname="Thaler"/> <author fullname="D. Wheeler" initials="D." surname="Wheeler"/>Platform Module Library Specification</title> <author> <organization>Trusted Computing Group</organization> </author> <datemonth="July" year="2023"/> <abstract> <t>A Trusted Execution Environment (TEE) is an environment that enforces the following: any code within the environment cannot be tampered with, and any data used by such code cannot be read or tampered with by any code outside the environment. This architecture document discusses the motivation for designing and standardizing a protocol for managing the lifecycle of Trusted Applications running inside such a TEE.</t> </abstract>year="2019"/> </front><seriesInfo name="RFC" value="9397"/> <seriesInfo name="DOI" value="10.17487/RFC9397"/><refcontent>Family "2.0", Level 00, Revision 01.59</refcontent> </reference> <!-- [TPM2] XML for latest version: <reference anchor="TPM2"> <front> <title>Trusted Platform Module LibrarySpecification, Family “2.0”, Level 00, Revision 01.59 ed., Trusted Computing Group</title>Specification</title> <author><organization/><organization>Trusted Computing Group</organization> </author> <dateyear="2019"/>year="2024"/> </front> <refcontent>Family "2.0", Level 00, Revision 01.83</refcontent> </reference> --> <!-- [I-D.ietf-rats-eat] RFC-to-be-9711: AUTH48 state (as of 4/28/2025). Update with xi:includes once it is published --> <referenceanchor="I-D.ietf-rats-eat">anchor="RFC9711" target="https://www.rfc-editor.org/info/rfc9711"> <front> <title>The Entity Attestation Token (EAT)</title> <author fullname="Laurence Lundblade" initials="L." surname="Lundblade"> <organization>Security Theory LLC</organization> </author> <author fullname="Giridhar Mandyam" initials="G." surname="Mandyam"> <organization>Mediatek USA</organization> </author> <author fullname="Jeremy O'Donoghue" initials="J." surname="O'Donoghue"><organization>Qualcomm Technologies Inc.</organization></author> <author fullname="Carl Wallace" initials="C." surname="Wallace"> <organization>Red Hound Software, Inc.</organization> </author> <dateday="6" month="September" year="2024"/> <abstract> <t> An Entity Attestation Token (EAT) provides an attested claims set that describes state and characteristics of an entity, a device like a smartphone, 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 JSON Web Token (JWT) with attestation-oriented claims. </t> </abstract>month="April" year="2025"/> </front> <seriesInfoname="Internet-Draft" value="draft-ietf-rats-eat-31"/> </reference> <referencegroup anchor="STD96" target="https://www.rfc-editor.org/info/std96"> <reference anchor="RFC9052" target="https://www.rfc-editor.org/info/rfc9052"> <front> <title>CBOR Object Signing and Encryption (COSE): Structures and Process</title> <author fullname="J. Schaad" initials="J." surname="Schaad"/> <date month="August" year="2022"/> <abstract> <t>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.</t> <t>This document, along with RFC 9053, obsoletes RFC 8152.</t> </abstract> </front> <seriesInfo name="STD" value="96"/> <seriesInfoname="RFC"value="9052"/>value="9711"/> <seriesInfo name="DOI"value="10.17487/RFC9052"/>value="10.17487/RFC9711"/> </reference><reference anchor="RFC9338" target="https://www.rfc-editor.org/info/rfc9338"> <front> <title>CBOR Object Signing and Encryption (COSE): Countersignatures</title> <author fullname="J. Schaad" initials="J." surname="Schaad"/> <date month="December" year="2022"/> <abstract> <t>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. CBOR Object Signing and Encryption (COSE) defines a set of security services for CBOR. This document defines a countersignature algorithm along with the needed header parameters and CBOR tags for COSE. This document updates RFC 9052.</t> </abstract> </front> <seriesInfo name="STD" value="96"/> <seriesInfo name="RFC" value="9338"/> <seriesInfo name="DOI" value="10.17487/RFC9338"/> </reference> </referencegroup> <reference anchor="RFC9053"> <front> <title>CBOR Object Signing and Encryption (COSE): Initial Algorithms</title> <author fullname="J. Schaad" initials="J." surname="Schaad"/> <date month="August" year="2022"/> <abstract> <t>Concise Binary Object Representation (CBOR)<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.STD.96.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9053.xml"/> <!-- There isa data format designed for small code size and smallan error messagesize.stating "Warning: Unused reference: Thereis a needseems to beable to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052).</t> <t>This document, along with RFC 9052, obsoletes RFC 8152.</t> </abstract> </front> <seriesInfo name="RFC" value="9053"/> <seriesInfo name="DOI" value="10.17487/RFC9053"/> </reference> <reference anchor="RFC8747"> <front> <title>Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)</title> <author fullname="M. Jones" initials="M." surname="Jones"/> <author fullname="L. Seitz" initials="L." surname="Seitz"/> <author fullname="G. Selander" initials="G." surname="Selander"/> <author fullname="S. Erdtman" initials="S." surname="Erdtman"/> <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/> <date month="March" year="2020"/> <abstract> <t>This specification describes howno reference todeclare[RFC8747] ina CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter oftheCWT possesses a particular proof-of-possession key. Being able to prove possession of a keydocument", but it isalso sometimes described as beingreferenced in theholder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs).</t> </abstract> </front> <seriesInfo name="RFC" value="8747"/> <seriesInfo name="DOI" value="10.17487/RFC8747"/> </reference>CDDL source code block in Appendix A. --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8747.xml"/> <reference anchor="NIST-SP800-90Ar1"> <front> <title>Recommendation for Random Number Generation Using Deterministic Random Bit Generators</title> <author fullname="Elaine B. Barker" initials="E." surname="Barker"> <organization/> </author> <author fullname="John M. Kelsey" initials="J." surname="Kelsey"> <organization/> </author> <date month="June" year="2015"/> </front> <seriesInfo name="NIST SP" value="800-90Ar1"/> <seriesInfo name="DOI" value="10.6028/nist.sp.800-90ar1"/><refcontent>National Institute of Standards and Technology</refcontent></reference> </references> </references><?line 644?><section anchor="cddl"> <name>CDDL</name> <t>The Concise Data Definition Language (CDDL), as defined in <xref target="RFC8610"/> and <xref target="RFC9165"/>, provides an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</t> <t><xref target="RFC8392"/> does not define CDDL for CWT Claims Sets.</t><t><cref anchor="cpa601">RFC-Editor: This document uses the CPA (code point allocation) convention described in [I-D.bormann-cbor-draft-numbers]. Please replace the number 601 in<!-- [rfced] May we update thecode blocks belowtext to avoid using "[RFC7519]" as an adjective? Also, should "Claims sets" be "Claims Sets" or does it refer to sets of Claims? Original: These CDDL rules have been built such that they also can describe [RFC7519] Claims sets bythe valuedisabling feature "cbor" and enabling feature "json". Perhaps A: These CDDL rules have been built such thathasthey also can describe Claims sets [RFC7519] by disabling the feature "cbor" and enabling the feature "json". Perhaps B: These CDDL rules have beenassigned for CPA601built such that they also can describe Claims sets as defined by [RFC7519] by disabling feature "cbor" andremove this note.</cref></t>enabling feature "json". --> <t>The CDDL model in <xref target="fig-claims-set"/> shows how to use CDDL for defining the CWT Claims Set defined in <xref target="RFC8392"/>. These CDDL rules have been built such that they also can describe <xref target="RFC7519"/> Claims sets by disabling feature "cbor" and enabling feature "json".</t> <figure anchor="fig-claims-set"> <name>CDDL definition for Claims-Set</name> <sourcecode type="cddl"><![CDATA[ UCCS-Untagged = Claims-Set UCCS-Tagged = #6.601(UCCS-Untagged) Claims-Set = { * $$Claims-Set-Claims * Claim-Label .feature "extended-claims-label" => any } Claim-Label = CBOR-ONLY<int> / text string-or-uri = text $$Claims-Set-Claims //= ( iss-claim-label => string-or-uri ) $$Claims-Set-Claims //= ( sub-claim-label => string-or-uri ) $$Claims-Set-Claims //= ( aud-claim-label => string-or-uri ) $$Claims-Set-Claims //= ( exp-claim-label => ~time ) $$Claims-Set-Claims //= ( nbf-claim-label => ~time ) $$Claims-Set-Claims //= ( iat-claim-label => ~time ) $$Claims-Set-Claims //= ( cti-claim-label => bytes ) iss-claim-label = JC<"iss", 1> sub-claim-label = JC<"sub", 2> aud-claim-label = JC<"aud", 3> exp-claim-label = JC<"exp", 4> nbf-claim-label = JC<"nbf", 5> iat-claim-label = JC<"iat", 6> cti-claim-label = CBOR-ONLY<7> ; jti in JWT: different name and text JSON-ONLY<J> = J .feature "json" CBOR-ONLY<C> = C .feature "cbor" JC<J,C> = JSON-ONLY<J> / CBOR-ONLY<C> ]]></sourcecode> </figure> <t>Specifications that define additional Claims should also supply additions to the $$Claims-Set-Claims socket, e.g.:</t> <sourcecode type="cddl" name="uccs-additional-examples.cddl"><![CDATA[ ; [RFC8747] $$Claims-Set-Claims //= ( 8: CWT-cnf ) ; cnf CWT-cnf = { (1: CWT-COSE-Key) // (2: CWT-Encrypted_COSE_Key) // (3: CWT-kid) } CWT-COSE-Key = COSE_Key CWT-Encrypted_COSE_Key = COSE_Encrypt / COSE_Encrypt0 CWT-kid = bytes ;;; Insert the required CDDL from RFC 9052 to complete these ;;; definitions. This can be done manually or automated by a ;;; tool that implements an import directive such as: ;# import rfc9052 ]]></sourcecode> <t>The above definitions,conceptsconcepts, and security considerations also define a JSON-encoded Claims-Set as encapsulated in a JWT. Such an unsigned Claims-Set can be referred to as a "Unprotected JWT Claims Set", or a "UJCS". The CDDL definition of <tt>Claims-Set</tt> in <xref target="fig-claims-set"/> can be used for a"UJCS":</t>UJCS:</t> <sourcecode type="cddl"><![CDATA[ UJCS = Claims-Set ]]></sourcecode> </section> <section anchor="example"> <name>Example</name> <t>This appendix is informative.</t> <t>The example CWT Claims Set from <xref section="A.1" sectionFormat="of" target="RFC8392"/> can be turned into a UCCS by enclosing it with a tag numberCPA601:</t>601:</t> <sourcecode type="cbor-diag"><![CDATA[ 601( { / iss / 1: "coap://as.example.com", / sub / 2: "erikw", / aud / 3: "coap://light.example.com", / exp / 4: 1444064944, / nbf / 5: 1443944944, / iat / 6: 1443944944, / cti / 7: h'0b71' } ) ]]></sourcecode> <!-- LocalWords: Attester Verifier UCCS decrypted rekeying JWT EATs --> <!-- LocalWords: Verifier's CWTs Attester Verifier FCFS --> </section> <section anchor="eat"> <name>EAT</name> <t>The following CDDL adds UCCS-format and UJCS-format tokens to EAT using its predefined extension points (see Section <xreftarget="I-D.ietf-rats-eat"target="RFC9711" section="4.2.18" sectionFormat="bare">submods</xref> of <xreftarget="I-D.ietf-rats-eat"/>).</t>target="RFC9711"/>).</t> <sourcecode type="cddl"><![CDATA[ $EAT-CBOR-Tagged-Token /= UCCS-Tagged $EAT-CBOR-Untagged-Token /= UCCS-Untagged $JSON-Selector /= [type: "UJCS", nested-token: UJCS] ]]></sourcecode><?line 772?></section> <section numbered="false" anchor="acknowledgements"> <name>Acknowledgements</name> <t><contact fullname="Laurence Lundblade"/> suggested some improvements to the CDDL. <contact fullname="Carl Wallace"/> provided a very useful review.</t> </section> </back> <!--##markdown-source: H4sIAAAAAAAAA+V963IbR5bm/3yKHKhjRXYDEG+6UbbGNEjZVFMSR6RG2+vW zhRQCaDMQhVcF9JoSo5+h/m7+2/fZN+kn2TPd05mVlYB5Lg7dmNmZxQKEqis vJ0890tyMBio60O9r1SVVKk51Ed69O279/oymulpXugP2bLIKzOpTKxHHy/1 KI2SRakvTFWqaDwuDHW+7504n2TRgsaNi2haDRJTTQdFVJWDejIpB2lUmbJS UWGiQ3p/UhdJtVI3s0P9/ujyQn/Mi6skm+nvirxeqqubQ32aVabITDU4xnBq ElWHuqxiNcmz0mRlXR7qqqiNKisackHvn1y+UuraZLU5VFrPMBANbha0Xn10 idmjKskzTTuYmLguzIXewvq26e1FlKSHGt++wbqHeTHDGEk1r8eHutnKzezR pt0pFdXVPC8O1UAnGa3s+6H+Nimu5nn6JxpHwPK9ya7CpzTHoX5VRHU2z6em 0Benl/TUQXqtwcga5zTKcGxHkcUSRKpoUtE7gIUhOL2fG1pGVURlafTTx9Qy yWNawsMnB3vPHz/Ed4L+oT6OigWBJa74jTqrCnr4nSkWUbZyW3k91O8eHudZ PpsTtN1mXpvCLFbtFt7QP9RROskXC31pJvMsT/NZYko6zMkw2Ny9L9mN/pjH PPQ3P1XJ8Cfbgfa6CPa59/S5fhUV2Tin057N9fs8iv1me9992D3QT88uen6/ wbvhjgmtE2D07wkDY5rA7vztUI+ixeAjPTWV3/nbKJus2g288VFSTnJ9sSor syibbWSTaHFDL34zQXtn/fuPH+/Yjh+jVXNMzx/v7h80x3QRZfp1XgLGhZkR DtNsR+EGPlwcqYFf4SgqaBGZ/jbHQWZugbTJa1OUSfW//1elv6Xjo1cu/9tp sJzzvKym0WSu9/d3Dg52/Pzysl/e8WDv2f7j55twRuvlPM/ond8dPB8c7O0O 9nafDZ7sP9/bbSAyicb5N9WfEiYylWGRFa0MRHtxefz8gN6gM1IP9PtXo2fP DzAPfXr6ePc5IcUN4P3t6Hxv7zF/G0+W9s2ne4/lzWc0HY3Bb54evT0aYrhB Fc3AMeinf3xTHdoeT3Z3qEccp/L9+e4TGh1kVeTprlJJNg1Xyb0XJk6iQbVa mtI/m+SFGSyjgk6BeFdpRz+gPRDrMpPBLM3LMipWdtaDgye0orS0k+7vHwgL ct+fP6VmY5b0/fL8zR6G09ry7pf8hRqKugTqnhN/xSL1mzyuU6PPknFBM+mL pZkk02TCrK9PBLBI0pX+y5//x95w5y9//p99fWauTap3dvrEKq+TEgxyZ3f4 +Lk28bDfmWSUL5Z11bBptMXE14kQd3ZxTqeD42HDGQ1YNv2wB/sEICUk5uN6 vvN4z+5z5/G+tAwyczOI0pkFwLOnBwSASTbV9t8DXZe0iiTTo+PjM51nKSD5 9vTicnBx/mxnZ/B856jYJfx8dzrc3Rk+2dl79gitw4vzoW9WymQVsBqrOjl7 dYipqnlCPHwwGBCHAtskZqou6ZkmmVYT6lc6NtMkIx5Vzc09QlBvfRiNLrb7 OgJcIi1og1+qMMvClJibwBeJ5P1oxvoyvyI63KJxtsOBbkj05HWl7UzolFRq vKKuZTLLoorkV18vDOHTzGhIHwwtx8xkqrfeHI1oJSTYTTYpVku0DBXWRw+i cWo3QyDV+ZT3MZHpCb4mu06KPMPOS30zJ17vF0LDE6zo23US0/5pRTkNU9BS oqzs67Im9hGVQHdaoQbPrjO/rjmxI5OWtChVWZwyP9Ob3BpOOhTwlyH2+jOw 0Kuc3oItRVlM7eWkSMbulOixkgPoE+xKgCGPCZB9fpm1gLIEYKFR0GYKnqWU 5piYck3Ss1Sl1VV0slimdiklQFZz5zpABgvA0mAD6of/Do2jLj8FHw/1Fm+M mEeVF+VDnUE7uUnSVI8NMfdFfi1AxQ4IMe2Lh9t//CNT2+UcJ8F4RG9bet36 y5//ZXdvmxlWRJIL49BvrM7jL0A/MyUPMo5ARtRxakw8jiZXelrkC57y9OTi O22uo7QWkAMUczrOsSEkLevxIqloozxKBEwhdqCrnHUvvbu3OxQiWiTESo0i Sj8FC41rxhuljjajfeQPWvZ+ezsg3vzlCyGajtKbaEU4WETLpdB+pHiQd+Mf Cej6goiBKYoWeuLxnAZ+d3HS55GIsXz5sg3sMmm+NEOFJm0RuNSg+UVOIwga EyfIZvzUZPGgygcGyABazotklmSqQ2qYNyFNdcYoEhCJIWzJV7IhHCSkEnZ6 Y+iso1LlvNAoDaiTsZkgQsjzIYt5MYQTyWxOx5cUdJCERBkhrd66vSWsxJHS zvoKnGI274eswe4PkKFPhKwY2i8dS20vfEIaxtg0ZF3NRaHCCogfZiX0UOwu n+Qp9yXNmKhA8MHjTyMpwSYyUCrxFcfLiBnQEIuE6QYjY/4M081yAgStMlyh aq1wqE4ze0Q3eRETlSbTkLtgo1FRQY2cR9fEEUEm5uek5CZHw4oU4nySWGFI o8nOCwMumDAqWxDcAywwFfRNCsd/aTXMUt2+iMCSCY2UZJNkmZqGWRDl5nVB R6hosWVCeJfkdZnS7rycTtMV7y3Si7qq8dXy0tixT5AFjBmar5wDwUx1A/Ks bnJViLmzNKR+CCOjoao5ySDHkO0YHv8Zx8xPdUIz4PyXRqC4RbjqmCDmSPOb bfBRzL4kNSYhCQJ4AQV4kAb3W9JBCHFCNpqVfAD1hDgQo2R9tz1JMElIWYkK C5CKxRDNTvrlgJhCR+j1ZRGEAyvZcJzE4K4hwRqy81ZgtIyatIuEEZV2UYLM O6Qd4rKlBwVFwcOQp6ETym8EjFFKu4xbC6Nt2SXlrcdMLILO3P5C88hmOgUI iVNRj7rIZFx/7hlG8XihOngxVJuEJtaHGVtik8ZZRMXVvea8qDLMnFmmh0IR oiZORBLiGCFeBXf4eJOM101mzRLIr5wRXjVG+LkzwgnT2AFArBpKI1i1pS9Y +tdmBZYHCuK3Rjl9W2L/+o2lvc3bjnMamY7fCj4vUw71EcFkwiN4toyt+w6L 6MppRYrZH8HLAZGEISHhC69fcCOkFOAMdwXbCACv0DuQXwVCAUAUnkgdSRLB lfFTTUgBHAebtJCDkBiIuhN7MIK/t4gY5KiEc9OWABeodTyJIdgRZU5kKUbQ KAe7rUoZKmDMCsfHUtFqEHSMzOKxOVFFqQPvt6V4TesCGKwCVcrvARyH102S FMd51zL8qMqNOq6TNLZKMgCVY3sQbMJPynxhtKjwMg0AcJ0DRaFm04bKZg7C jQcP9CUZpwl7GVbAFVoGPRBcx+GxUcHaDLDkR2DJsHmvtC/+3tARycd/JPXI CHftqP9RYYLhlEO61nBCBabo20/Y6kmj+vb1CXgnoTkssnSF5nNmIZjvH00B NanozNRQD00FkB6q+3x1W+X2CznKRbSkL2wASCu4vsU7q4VSV2Ub35sZCdTC Aj4S/Z7YKLTJKTGypCj9UABYKTBqgIYDuRAcHgkOY6G3t10bjnS/Rtlvd8AK pzkz3UNFiujtYQTl/Qt9fKm/+jtCN+YGxIkhOkGbekzEe6V/qgkYfUKvCoT/ X9+cXe8z0WcPLROXXQ0GMK17R7Sdai6syOo/BSvUUAUDiSuoCIFJbzI0MkZu jAWXR1YyjyOEnOJUqyRKCXP7geoFEJFxmEah+tgPVUVtWX5XQPllzM0dyxiy wSBcA+4aC0IrBb2YFmZFGnbB5gfro/mMVO55Munr5XxVQjGB1aa995S+LwxR G1Qx6JaYdZxkTlwSm8ynwx5O6JWwc72sC+AKo0gV2DHORiEOCKVgAr2S5XNj V4VWZLAPJoAp79hLCs8TBPQiiCLiGXAhCogItCH309AYnermjAPPsa8j0kHG cLlsPAS4SDbp//3ukcOzufW+e87ase/YqkukMqa1ZX8ZhJ0Ylc6uhr+Dn27J 490doh7nzSLZOYQz++TniIwPU9rBTAie6yTS56NTYMPWOTGTJZ0UbWrkUEbc 7tQhg3V18jMOiRjE6fGJ3jpt4ewxUQIm8+bLtuDB5RmJxdoqJEeEwcL2CkMk BLYW4zXHY1hWJOwuEHCDp0TLpCKY/cm1G2vQwiRioRw4ZixrvSJNnu0C3Xvz 4eKy15ff+u07/vz+5B8+nL4/Ocbni++Pzs78B2XfuPj+3Yez4+ZT03P07s2b k7fH0pme6tYj1Xtz9IeeCIPeu/PL03dvj856fl/e/sbGRJQBWwoCa8XMWzmn RSxs/O++HZ3vHhD/IxuP2NTe7u5zqETy7dnu0wN8uyEElCnhA7NfYc0oWMlR wfotQd5CsmRuUs7zm4z1F4LZb38AeD4d6q/Gk+XuwUv7ALtuPXSAaz1kwK0/ WesskNzwaMM0HqSt5x1wt9d79IfWdwf84OFXf08mGakgu8/+/qViVeCiKuoJ G8jMhIITUiStayiUBPtxkZgpAbbRd53RUnqP01AFRjjoF4RC7TOTMUVRA/yI RGIk4ifM9NraW9lXIseE8COvwLppQQ/ecqTTXThqYO3m52qDUqysUoxHjuIZ rTgEJxqCIA6Rn9iWUKcWOYkH2thNVMSDNM+v1r1iYq3xUlhlS5w1ziuwKyoV T8YNXh/hpWTW2WHpnF0YX32VRFmEBeEzYEkN9FXZrwMfGhh45uHX794JXPOt t7YtcIfMHvxI1A9ufjoxbwBbL20qPEksQiuhygBbxHMawUZQGzt07Cd9E5WN hBUVzSqD4gFk/5AYeDjAhDAMLFUfN6OekelS4zi34PDe5iF49X0lRwHFPRon aWItzLTMvRe0tQM5a7GnVagYvu6s2mnAeuvDa5h/zpSDBG32C+Q3ImVaoMz0 VnAg29q+I44t0jcHl9FsRrMKAXVPxkRVOBo7+YtaHNXQN2PpOLBe9QouRGrL 1YmYA6F9eSmNWydHl/BKG7YAeYJt3cCO2LCVRIrQlzpwfDhPrOlAZ4FDEgZO SPeBaYvOmnHh9oHwC9K4+Xk5MVlUJDnk7nWeepWibcYKsKEAisNqUuNIQEV9 54cBL6hoPqJGFoKscwbIxgaedWa7EAPrm1aZ8AorbYvtOHxf5kXlVb04mTKp VHc46IdaHzFqElKS5FJu0YysAbYEYtw7bfE+baBOxBqV9dGA3xOnu4bZwwZu tLLDO7ujMN7PFZulyWLWAvFu7A9B+npnHok3Qf6kUSpjc53AdGrUZ+uqK/Np dcOzVNHkaihqqcVPuE7FSrGasawELpYqx4oARTnGRlu2Uz0sfXjsxIcyAntO b12enHgMRDgPKEiqdHRn7G7r8vyN64HAH/Q6dcLiQYyaTNi28yYOwDjpkPko wihKv6Fda6MLJbWcf5siNcqjjPjgia0IcFMzY+9V7iy/BiWseuPARBD+ODcs IsRpGHm8VM6owgT9dQsvYcIsSSzHdtCOos8uXSjEzEckKiLs3jp7WcYoQ4p7 XmC9dCSdObrimWDqJDeLR3FtNMyUxVzdoXN6U01yojPaSRaLg5cpWAJnPjjV YDBzldG6arAGg9sHTrlA2KTTaB1kHc7CU2XGxGXox25RTODfZUS4yes0FkF+ AwEUGoXWdyuRA0g3dsFXYlzPiDf1rSZQOsHCiOmiZR31gVZEosbJF9LPvnxR XrMhDJvl1Gu+0D0yekyPzvT29sLaBPvDPVZ1JMb/je8PSq4QfVe3h2zcf1Ev 9R9/GA6Hn8SBDtkGd21ozrLjtBF/QZCHdbAG78lOA7Ny8UxYNbxetTacph0z L/W7EMIrvLs5y/lcWEQvlynsJ4a54kmwudaggX3IgAOEaC8ElNNMFsSqaD+I 37KnUmAXANPKAzpyuJUxr/cSWrvpruPynv++NsPZsC8c/sItam+426dz2e2z fLnzgGSzMEbwP0rzWV6XwvvzMPhsVauGYDk62bWhGP8amSnbd3DtfaChjuDB WBYJSP7IH0YPymaATGrTWredsQz3fp43DhE7XOuAVHPSTB6lqdiNVy9daNnF 7LHENvEOFQQPsrMi9vGJdGqfP/Jxslk1h80GAoWDgDDSRGUFMFEzApYRGNCq 0/XKWJ2ywzJciNlxUiUsAutkQDu8h2ZHCMJpGGaCGCwO3n/zkqPRtTl84qyI QDivmw/ewAmWvAK4k4nX8WiIJuqUZMr7ZFj5AXduQN/2+NtYr08iYV9oGwqi ZpAigGC2qXBeHAmi1ricw+/vQ5y8Gh9poX2QilqyB14Msyu4gyUzAkvcMEIT ouMDUVviDLLeE4RPt9tBRkJLol94R8bEHbSoQFPL6APhPLSU6xcCOgegMn/A Af/vuKE6cV87vg/xEidph3BLJ0O6WLz1ccPmbcytCaJ2g5g+dKGchL0n6GbZ l1e8rENaAmoI7a3gcg+DbX0QCQviVqSsG0EdbpNM5RjLVQaniDNTJMbCHL+D OUAXwhZ/uIkQGaQCtLqUsK0BA8eHFNoKQ+pB3HTDjloHJdzDKmBOmMNvVgpT vOGYp6A+JA3CqLabDbSxYtJBc2GNXiNSzrsW2LwtH4MSJtSE7koTmgJy0mLu tzKDoiKI4bOmphz6yW54E32vH3R4guPdBAzH4znUPIU7grdvMQCDsubkXA93 xAJDtwdZZ97n4SKEFgxNnhCU+CpKUtbqQ92u0d0EIKrrc0mQZZX9WGcyJMfI 2BqvAI4oqxpOGOqEQruh2EPYa3R+9GRnV+d1xeRmiTL0rGj2zk3AZiUcF0v4 NUpZlBSSYQPsn6YwzEDld8h2AuRmj3wDoT4LFp6/yFPjjkFUSXHD2uQUMzFI KnVLFrt+jeuGdmkCTYmgJ3kqw7vCAwmJuXbqIt5ZGKBlUi5Kz+c8m90QKQLW 1jgzxbFIWtlpOzJtESmwbv2OAHDVDdm77cO1Q1zIbduvgQ0++3BN7AvDg5Ts t8L6fLSOY66x5raBHoR8VDv7xZ9WKRoGOw26zJ94VZiHCmdas2m2nbAGXhDR cjuPwVrUNlMBBt1knhjEi5JpCzYczxIoKs+BW5CEw7oB2l16EihFgjYeGG5c Mro35GFJDn7yp8iSZJpCmKU11BTMWc1tTpVdKdASfDB1dqxFX0zM7iBOCLoh tWoDcqGzF3NlWReSmsV6A6ceSr4YtsvZUbAtyNy/IR1rvtoc+u04PtQGFzJr BowWLa3vXrqwQwlJsOphNnmn8XjzsoivmXQqB+K32hiKLGrboeqOB+futC4d WKQb6WaD6a+a7Iuc1oaId1olpDMYzhRiZwPJamtiBCizzNNkwrZHjPzsBWID Hi1yaxwpm5PgUyIDtG71ZL1pJWyk68CA6ki6emZmeQXzYag+zpO0bYx3paGj 99bBBtquRPuhYls3Lq1GkqusK2DDYF0lRswJ9udEsehvAiUBjWJ+MWNVidDY oBSARoJ1vJmpdbx6FsA2cb5UkpTr/JZlwJAtBxZHRjucJ9oGUddmZCxNcS0x XI7xxuytDV0oqoU5jSoSWWWkdQYNOrscONlpVKnN07OXoI3s1m8E9Yx+lj59 afMANggIfdMqPNYNgkqY5KfawKtq012q3KXS0U7nEQdPg9ix8JUMOkc0uUJm pOOmdKik0fIT4hdk7dGaZpZoHF9i57EgOZ31xsUOSU32uX5sDQMjFpyROmbc 8fu4j31kCiZWQXKo7Z/0zpVIX56cNO5RG0c+f+P9n4IWmWyA5sNmPIF2pb7w lzb1dzzH61ynkx6Z5TolG9smvcJIdkynbwUCGQ5CjbUkItsJ2dnq0auZR1lr XbToMO2RBbUNs/j0HhMewmlb+GFKnzambdiubLB7JcFmayqwA9zl8q786VNL kG/mhrbCryvqrA7qU+RmOb1L+FensoCFZBiVTllmIMDNk7h3Sytbya5hlPwr IzaZYUe5DzrindCrczDcG+4+G+7rrbfypgy2DVePHaMf4IpnEX5HxEjyAjmp a1sKginaZUVD6Jw0qZr9JnPEZZk3OXZbjMx2A7TubeLCiUljcQp08sc8Ttv1 hPpkG0PJAH+bVzbdhYa1VIkYmZ+N1RAevW8FP1R8OE1F23CbFzcdIbD1IFtY 2wd9STIgXrQGHLKj2Z+97ur50IoUv6t8pHhkI8VknwVh4q6B5uPuyLAKbJ2u A/5fsdIk/e/YRi3iEN3IxM4sLbYNv8TqcNYXMB64fD15POcIMOcjQhVhd9vW NAwlEdiuiI3xmXn26Opy8P1nF62lM8uSRb3YVq7MoqtlNv5n5J+mkjsycLGc lmnQhz7A7aTXuZxNeEN8wqHeAlH1ONWnTAh3jjmA1eu3fO37TDM2Fde6mkIo LLmeg21n8VAkViP1ArSbE8mmaBY3VTk6rC7o8BrLRlsLl1W098JelAnXo/Fa 2moTwXIe2qQcqbEst/QHOQ8iwfZA2Z2G42ySMMPDVS72d2xI5M5NPLioxwuO 2g2OkxktDbLLNTJdfltnMWJ6DYwf64YrCYaeF8l1RIrTOTLiimuHoGs+XBY8 S3nJRu+WtmtLgUc5lqSZYRdqgzjSOKzrKLUaieiRSI1kWg/cfmkyNYNyGbmc COX8jkEFggQmrBrUF+su8iuz6wXcOtzXZ0GsBffYcnXOHVtk0bbPEevm9G6E 31Jnnrt6OI+UorxDyttse9tfmKOv3yBtZpVb06id9t9F0G79j3OpwWeXBeCH +u90cm9kQAEQdoXqLUnwh3hsoKXWoBVIYVs90zl5Yn11FqR/o16K4/cqygKu 1Lid8BGY+eHk9NiGbruiNMBQjC96469dqK2IiBpthpVwd06NdYV6pWyW3qUp R5OCdE+NuuI1Q0aQkPNbk9KG2VQABBcipy0PJG9ry8ax7jV0adXKp7viloFc cun0lJhqXqy2mZu1wO10ks4Md+yJ4+C0qMJmD3BhTTbzHusJmYkxcwWuKO6K 1tsHnDLFTMPf3VBIVrblGtbD5VpL18zOH5Q/Iy7XydxwZ/+cA3nK1l1/M0Dh NHxEvBSO+8I+qazNb2sixBBGqQCGQuyIvgyuOd2b5sJJs8XeqkQmE8pKC+It SGfd/d0eYcOfzHa/Id5ugrCKbMZCayQfiSKofWaA0L/Pkkt1SqoOfb4whETs 57jv32fqbj2xn5EYr7dEig1YipUIozbpY0Qgf/zh9va/oIT4y5dP29TlnrLg 8FWa5/ZQP2gDiugjLb9+WOhUpw+lxvvrnqTMM2vESfa+oJB0sow+ud9cuzw4 kRJR3S5Yrh2foC3pLa4IFlPZnhsSdm1598Rn6OlWNuoPKOceyyUCjAsDufsi qxdjQvhP4ry1g7CzoHYJUowTqLLo0fSkYSwRvHQFru5wp8nP0m6H8NpvksXW 6cjQaVLkJ8YKASKKOmDz/JodhUx6XywCxH3B8W+k17Si0DCiCM61L7xEwqxE 5WWcfCJx/UkrY92v2Zls3nNBwJCcSlc1391zwtq2EZH/hq8PuIT/COq3ReZH iFn8DqB2tRY2tvmguW6AsEBtJsg4bsd9wkmsXtXjRxqPyp4KWEP3TgO2uT/r t7DkhDr0JYQ1CL5NNbRSS4Ab6KnZz+c79vmZJg82x5TlicXSCkK6zTuOPJqt tIAFMqFeEJfEtL8ofoEvxlCH4RqUIt2tChv9opTy7Cm8zeFQZ48ipd65yt0N bScuLa/tj0M7iiMI1FvMmcXoJ+60baMl6w5BqYzxabEtuIDN07zQ5lz653pn ZIModV67OtEW25TR/XBHy6C2nfVjKdeCcGUwA1Dos/6ijx3fW29kb0ZgLQI3 L7QjREq9KqKZSEgOV7DasL4ltkZWZE79bM0Kx9dJajkesjaOBCvCGnOQey9E Rxw6ko62jipHvACblTDdVHGX3cMEvT6jL1PBP7taJ27vmJmw4CiM6HkNFJs+ xs0RNgaTJrA/CevKxncqR6P1oX776AgFN2+iGdlAwqUJ9K22V3BD+1xX3zqU W4zQdwLLn2yjKTusQR8QHu1xzgmqLhEVl7q4/HfrbsVtRGGFYHdHcuPTd3zr EoiFELSSu5j87UvbguJZ7EKz6IdCgHdvQZ1E7InNRaJ1+BcE5Y84DvRoJJWf 1hudmgJvyC1R93HgH4kJ/FiyinIHBx6g+f8vNuw39fmOzbbZsOzwV/BiftEx 5NcX797q//tc2a3x/ylX/nD5avDsPygzfr2BGb/+98uMcdb/NsxYZv53wIx/ /E/FjNmalYrtwSspZyjavBccYzO3lRfZM9EZQkDu1PTeKD86V+1Xyh6sAMd9 WwX4vVGQUv/+5OJyWqfqJMx92hrl70+2EQK03Kanu3y8cx0Yly6Vqile/uyW LOwy4OXu+UjY1md9enwHlwd3v0uxHnRFxOW3x2LdkhlbbWbvtnLe1tgMaEuO u3fA22Lumk3Tahx/cr8Pw9uLGlNIbDi7DpvPZw9KLmXgK73WjTi9hQ4IEdSz GR++OEk8u15zlDhefX+eM0PA+jkkDjL8Ne9zoUuQvsYnwHUi1ryEFSi7ddkt U5cqhhoghIqs8RrdkTD0AnHTJttZ9ySxAT5P8dEukK4bZe7SGh+khOrtMnqp D5y6UsCRNyXRUeWcqcmSE7KQzbKW7BRcpoKLJBfj1NjsEVuzg6oYG2a0M/eG qlUX2URy7oIoONNa+iKtn53dkgXoA86SB9j2c7RqWfz1FEG1VOuKsDDxUeV3 lSv4AoswUc+mHZJg+mCz1MQtapP2qiCtjMu5OAorLmoSsy59Ncx1kMIVHqXt 0sKdVOKNVoHPtnUBR1+3Ck8IIaiTxQ+fkhmkiUaSAmdTliNZ6sBnZN8BhyBL VAJfleKbwHD9Sz3hhNtrwzdAMXDdBQICPtFb5OKmIhY3MGjFXhxUB0lXzcFx sYC46jn0xevsqw0heprxkT2mgAE2ubbWHYs0XAfMJn3X6SN8Kkdn52+3JetN ACJ8iZPpfIqfzTThElf4g8u5BAgsKW2KsaCuw4c0eJuovl9LLQ6vcZA5gTnh FTDiMvrO1ie1WR3JxVaQsVzPR2qnvUMgVUH6RKh84yLWSRPo9JtqlTVJXGRB 6GsvaLoz6Z+tHSTXdYrc7aVsjCf5uLJ31eGEfBAxxbWUUhrlU3RshQZJzt/q 7qYdM3b5MmU9JbxOLIfwGTN5IQEM1IRB9aWVF6biqB8SyIokSjdk0OXtNJBu ouJvbbg78tFDLoUgMGac0d8uyCFReNUKMkVj5ERh95oH4AQWoWTkjy8WTMyY BlcX+bH+ymVykARXo9EsKZ2bP0gnf4HoycIXYrjCAp+q7m5xw/oR+tabN4F+ WKsLoEr8RLK5XSI/P+osL8yi4sjeGCt1myzrJVdlcQ6lr4NH9S7ntrpyNlOY dbjQMBtuQOtLZgwBWorgRJAhBIOr9oDVksRIe1jZtBgfz/JFdl2BShYQKb8u a2MTVqlfe1ycYOurtZo4lyUCJREpdzlXyURxguUIKeEIsxVc34tEYmXa3X1n z5KXl98Q1ImVLZlFQJ6wyciHK3zv16Q2OwK4M3cxqKRKV837LQABKSYol2Ba lwQG2oGEFIrQyGjuQpnS83kGW4cd+I40wreH63AJyrrCSjupZtA2zJB7M2qZ V4JlQKQiAl9hRW9VJqXNvbMXTfmas0aw3q2g2poq1S24uq/E6m61VP0NxVWb S6Y+N9v4Fd6llp9psP5v07O1dzDnycVg9O1o8OZo5OdsVe3ZoHRnvdr1/W70 pmXqhAHt3X+l7+ievvfNS/hP//d2Hp3n6Wp3f+dxp+/+nX1dAFAO3VlYvx59 2JuGm1ZxeyunYB0fnwmT+pV3SfTXgsD2aglOlWHEkNuvYbWGFzyQIbdyUfDF OJnVQUmnkeuClL83o7QS16pdPt0icpeqigAJvFysCJJohi+RbQlrbPlkNVmz XA5h70tt3xppg6NkL34KPv5bh0pt//O2IRyIX7Zv3f0utAK+tKyUizetpWzH kJioV9JYIff2MoNEgtgSNV0LPjKSAHoLmiaVs58ms4EYdYPSANy4LKjUc1yK Jpo6I9jU3dzkb8tqh7k3XAfB5rTtL5d5KL6flVeNq/5sFrAToSsxVrk0w9Xe +ztJRs39ygQSRbzMXro6NXLrbY/DKfaCjG6bePeU+uWXX+Sud75M5AOpkHwn yde6CfdL06VrePBkSADdar2/rVSQHvC1vlX6t/o3v2meDeQjHvOnwVlEh6mH fj3s+CPNzkE+RXtPf/0Sck99UWGvr+X6lHdvz/7wFWHmS/1II9ERlEZ7HBC+ EZugt/ih2rAM/ejR13qLtIpSppPZMFl7iO17OiMP8G/uHNXx396ZGEu38y9Q Vu/tlI2nf30n0gr++k7E8LudxivkJRKSrEFcvx591aOnvb7efanWYMrN9JSa 916qNahxMz2l5v2Xag0u3ExPqfngpVqDADfTU2p+/FKt7VWWFlXU/OSlWttV gINPX2r9Qv9YJaD11x8vD4MrZeARF5ObkRGcXDq9fokpAgpgilTNqCO8MApe YHJWtKrXfW5rjfVIhz1B1ixX27zMey/BfzpeoeY4IU9b+UlWIllhE2QgOxYU VNLANklXyr3kr2zYhC+kgV+ZSi5VOAxY0Qv9g/2LB5/uwbNnh+C4A/xJhG0C P/1W7jszIL21K2/AwTj4vVltU0c83pPH9q4+E/8TXvin4IV9eeEqIb5GsAjH wJHYt9XmQdwbtgUHE3zdUXZkeo2pQqkXL17o06w0hXNDusxhFupwTMB5jD8R 4W6aSY34JEvDnYOiIvaiJb7GNIbBTVJYqg7l0vN8wUYPSne4d5W7An+fn82q jbhUCZMLyexvbKsXD1xjMZ3wn66w2CYX8EBgD4D2X/e46LjBl4FNwCyHOOae 9UaTsXwdXqdV9l2+672Vu+5+L8FJIQa+B8rEAS5DsaOn0bKs06hy1jbuD1EX cpEzqW5WWwh6Wfix0VHYSDaSFXudSKK7CxZU0+f216OL3rBRK9q3ov1zM8U/ 36FrhE4GuWxGxgzpAw/aEhoHQIqvvevSFhDg+sMsTn6G9RxcROZrOqXMf1PR xe3tket75NT2m2B1SNa1VRGuQpDwieCc5jaH3OXcw4tpdTpRxGQfv2hRC5No pqDsbUGbuxWV7hHkMv0k6u1N8mh5+OhRVA7tcvEng3p99yJJBvpJ9Nwjq/nq pmkgmUA/95sRUnjNNw9CAoJ+Hhzq3YODg50nB88PDnwbSQf6+Zjb9qkhbCPR QD+fbGwjiqGfTw/1/OHO+Oku/niR/qJIAv7CJ8U38+ozVDF8xD2dh7pJlvZ+ FXtZkuUvhItX4jtFABslP4pv590wlBvhYSlFO+tDvxq9upDuQJqjSyUo0SRp MO4S4ZatO+b41rfXG+6c4wzqTRfJ6e5FclJ20a1VoqdcOSCXLzfVAB7jf0MT DII78wbyFzNIDgS6afCW00s777nHpBQyv7gwqYHjCC/8wMFqS219W/gz4C0e 8q4/CZU1hubRBBdmpCYWJ1epvu78I55YZ4L9Jmbfxu1ZVIvj4KzO4nEaxeYL DAwXxxPHRrLg0IGwYis/cSK4juZ2FBWp/kgMnUymL42HBNGca1PARWSmdcp/ D8XcDNX/AUuUe8TobgAA[rfced] Some author comments are present in the XML. Please confirm that no updates related to these comments are outstanding. Note that the comments will be deleted prior to publication. --> <!-- [rfced] We note that the abbreviation "UCCS" (Unprotected CBOR Web Token Claims Set) is used for both singular and plural forms of the abbreviation throughout the document. To make these forms more distinct, we suggest using UCCSs for "Unprotected CBOR Web Token Claims Sets" and UCCS for "Unprotected CBOR Web Token Claims Set". We would also update to use the correct article for each use of this term. See below for some examples. Current (A): As UCCS were initially created for use in RATS Secure Channels, the following section provides a discussion of their use in these channels. Perhaps (A): As UCCSs were initially created for use in RATS Secure Channels, the following section provides a discussion of their use in these channels. Current (B): When UCCS emerge from the Secure Channel and into the receiver, the security properties of the secure channel no longer protect the UCCS, which now are subject to the same security properties as any other unprotected data in the Verifier environment. Perhaps (B): When UCCSs emerge from the Secure Channel and into the receiver, the security properties of the secure channel no longer protect the UCCS, which now are subject to the same security properties as any other unprotected data in the Verifier environment. --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </rfc>