rfc9781v1.txt   rfc9781.txt 
Internet Engineering Task Force (IETF) H. Birkholz Internet Engineering Task Force (IETF) H. Birkholz
Request for Comments: 9781 Fraunhofer SIT Request for Comments: 9781 Fraunhofer SIT
Category: Standards Track J. O'Donoghue Category: Standards Track J. O'Donoghue
ISSN: 2070-1721 Qualcomm Technologies Inc. ISSN: 2070-1721 Qualcomm Technologies Inc.
N. Cam-Winget N. Cam-Winget
Cisco Systems Cisco Systems
C. Bormann C. Bormann
Universität Bremen TZI Universität Bremen TZI
April 2025 May 2025
A Concise Binary Object Representation (CBOR) Tag for Unprotected CBOR A Concise Binary Object Representation (CBOR) Tag for Unprotected CBOR
Web Token Claims Sets (UCCS) Web Token Claims Sets (UCCS)
Abstract Abstract
This document defines the Unprotected CWT Claims Set (UCCS), a data This document defines the Unprotected CWT Claims Set (UCCS), a data
format for representing a CBOR Web Token (CWT) Claims Set without format for representing a CBOR Web Token (CWT) Claims Set without
protecting it by a signature, Message Authentication Code (MAC), or protecting it by a signature, Message Authentication Code (MAC), or
encryption. UCCS enables the use of CWT claims in environments where encryption. UCCS enables the use of CWT claims in environments where
skipping to change at line 154 skipping to change at line 154
using approved cryptographic, physical or procedural methods, using approved cryptographic, physical or procedural methods,
or a combination thereof." or a combination thereof."
For the purposes of the present document, we focus on a protected For the purposes of the present document, we focus on a protected
communication channel used for conveyance that can ensure the same communication channel used for conveyance that can ensure the same
qualities as a CWT without having COSE protection available, which qualities as a CWT without having COSE protection available, which
includes mutual authentication, integrity protection, and includes mutual authentication, integrity protection, and
confidentiality. (Replay protection can be added by including a confidentiality. (Replay protection can be added by including a
nonce claim such as Nonce (claim 10 [IANA.cwt]).) Examples nonce claim such as Nonce (claim 10 [IANA.cwt]).) Examples
include conveyance via PCIe (Peripheral Component Interconnect include conveyance via PCIe (Peripheral Component Interconnect
Express), IDE (Integrity and Data Encryption), or a TLS tunnel. Express) IDE (Integrity and Data Encryption) or a TLS tunnel.
All terms referenced or defined in this section are capitalized in All terms referenced or defined in this section are capitalized in
the remainder of this document. the remainder of this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at line 177 skipping to change at line 177
Section 2 briefly discusses use cases for UCCS. Section 3 addresses Section 2 briefly discusses use cases for UCCS. Section 3 addresses
general characteristics of secure channels, followed by a specific general characteristics of secure channels, followed by a specific
discussion of using them in the context of RATS Conceptual Message discussion of using them in the context of RATS Conceptual Message
Conveyance in Section 4, and more forward-looking considerations for Conveyance in Section 4, and more forward-looking considerations for
using UCCS in other RATS contexts are discussed in Section 5. This using UCCS in other RATS contexts are discussed in Section 5. This
is followed by the IANA Considerations, Security Considerations, is followed by the IANA Considerations, Security Considerations,
Normative References, and Informative References. The normative Normative References, and Informative References. The normative
Appendix A provides a formal definition of the structure of UCCS, as Appendix A provides a formal definition of the structure of UCCS, as
no formal definition of CWT Claims Sets was provided in [RFC8392]. no formal definition of CWT Claims Sets was provided in [RFC8392].
This employs the Concise Data Definition Language (CDDL) [RFC8610], This employs the Concise Data Definition Language (CDDL) [RFC8610],
using its ability to also describe the structurally similar using its ability to also describe in the same definition the
Unprotected JWT Claims Sets (UJCS) [RFC7519] in the same definition. structurally similar use of JWT Claims Sets [RFC7519], without any
Appendix B provides an (informative) example for CBOR-Tagged UCCS. protective wrapper (such as JWS) applied, as Unprotected JWT Claims
The normative Appendix C provides CDDL rules that add UCCS-format Sets (UJCS). Appendix B provides an (informative) example for CBOR-
tokens to Entity Attestation Tokens (EATs) [RFC9711] using its Tagged UCCS. The normative Appendix C provides CDDL rules that add
predefined extension points. UCCS-format tokens to Entity Attestation Tokens (EATs) [RFC9711]
using its predefined extension points.
2. Deployment and Usage of UCCS 2. Deployment and Usage of UCCS
Usage scenarios involving the conveyance of Claims (RATS, in Usage scenarios involving the conveyance of Claims (RATS, in
particular) require a standardized data definition and encoding particular) require a standardized data definition and encoding
format that can be transferred and transported using different format that can be transferred and transported using different
communication channels. As these are Claims, the Claims Sets defined communication channels. As these are Claims, the Claims Sets defined
in [RFC8392] are a suitable format. However, the way these Claims in [RFC8392] are a suitable format. However, the way these Claims
are secured depends on the deployment, the security capabilities of are secured depends on the deployment, the security capabilities of
the device, as well as their software stack. For example, a Claim the device, as well as their software stack. For example, a Claim
skipping to change at line 207 skipping to change at line 208
also the delegate to compose the Claim to be conveyed. Whether it 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 a transfer or transport, a Secure Channel is presumed to be used for
conveying such UCCS. The following sections elaborate on Secure conveying such UCCS. The following sections elaborate on Secure
Channel characteristics in general and further describe RATS usage Channel characteristics in general and further describe RATS usage
scenarios and corresponding requirements for UCCS deployment. scenarios and corresponding requirements for UCCS deployment.
3. Characteristics of a Secure Channel 3. Characteristics of a Secure Channel
A Secure Channel for the conveyance of UCCS needs to provide the A Secure Channel for the conveyance of UCCS needs to provide the
security properties that would otherwise be provided by COSE for a security properties that would otherwise be provided by COSE for a
CWT. In this regard, UCCS is similar in security considerations to CWT. In this regard, UCCS are similar in security considerations to
JWTs [BCP225] using the algorithm "none". Section 3.2 of RFC 8725 JWTs [BCP225] using the algorithm "none". Section 3.2 of RFC 8725
[BCP225] states: [BCP225] states:
| [...] if a JWT is cryptographically protected end-to-end by a | [...] if a JWT is cryptographically protected end-to-end by a
| transport layer, such as TLS using cryptographically current | transport layer, such as TLS using cryptographically current
| algorithms, there may be no need to apply another layer of | algorithms, there may be no need to apply another layer of
| cryptographic protections to the JWT. In such cases, the use of | cryptographic protections to the JWT. In such cases, the use of
| the "none" algorithm can be perfectly acceptable. | the "none" algorithm can be perfectly acceptable.
The security considerations discussed, e.g., in Sections 2.1, 3.1, The security considerations discussed, e.g., in Sections 2.1, 3.1,
skipping to change at line 237 skipping to change at line 238
initial algorithms specification [RFC9053]. initial algorithms specification [RFC9053].
Secure Channels are often set up in a handshake protocol that Secure Channels are often set up in a handshake protocol that
mutually derives a session key, where the handshake protocol mutually derives a session key, where the handshake protocol
establishes the (identity and thus) authenticity of one or both ends establishes the (identity and thus) authenticity of one or both ends
of the communication. The session key can then be used to provide of the communication. The session key can then be used to provide
confidentiality and integrity of the transfer of information inside confidentiality and integrity of the transfer of information inside
the Secure Channel. (Where the handshake did not provide a mutually the Secure Channel. (Where the handshake did not provide a mutually
secure channel, further authentication information can be conveyed by secure channel, further authentication information can be conveyed by
the party not yet authenticated, leading to a mutually secured the party not yet authenticated, leading to a mutually secured
channel.) A well-known example of a such a Secure Channel setup channel.) A well-known example of such a Secure Channel setup
protocol is the TLS [RFC8446] handshake; the TLS record protocol can protocol is the TLS [RFC8446] handshake; the TLS record protocol can
then be used for secure conveyance. then be used for secure conveyance.
As UCCS were initially created for use in RATS Secure Channels, the As UCCS were initially created for use in RATS Secure Channels, the
following section provides a discussion of their use in these following section provides a discussion of their use in these
channels. Where other environments are intended to be used to convey channels. Where other environments are intended to be used to convey
UCCS, similar considerations need to be documented before UCCS can be UCCS, similar considerations need to be documented before UCCS can be
used. used.
4. UCCS in RATS Conceptual Message Conveyance 4. UCCS in RATS Conceptual Message Conveyance
skipping to change at line 277 skipping to change at line 278
achieved if the sender and receiver mutually authenticate when achieved if the sender and receiver mutually authenticate when
establishing the Secure Channel. The quality of the receiver's establishing the Secure Channel. The quality of the receiver's
authentication and authorization will influence whether the sender authentication and authorization will influence whether the sender
can disclose the UCCS. can disclose the UCCS.
The extent to which a Secure Channel can provide assurances that UCCS The extent to which a Secure Channel can provide assurances that UCCS
originate from a trustworthy Attesting Environment depends on the originate from a trustworthy Attesting Environment depends on the
characteristics of both the cryptographic mechanisms used to characteristics of both the cryptographic mechanisms used to
establish the channel and the characteristics of the Attesting establish the channel and the characteristics of the Attesting
Environment itself. The assurance provided to a Relying Party Environment itself. The assurance provided to a Relying Party
depends on the authenticity and integrity properties of the Secure depends, among others, on the authenticity and integrity properties
Channel used for conveying the UCCS to it. of the Secure Channel used for conveying the UCCS to the Relying
Party.
Ultimately, it is up to the receiver's policy to determine whether to 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 accept a UCCS from the sender and to determine the type of Secure
Channel it must negotiate. While the security considerations of the Channel it must negotiate. While the security considerations of the
cryptographic algorithms used are similar to COSE, the considerations cryptographic algorithms used are similar to COSE, the considerations
of the Secure Channel should also adhere to the policy configured at of the Secure Channel should also adhere to the policy configured at
each of end of the Secure Channel. However, the policy controls and each of end of the Secure Channel. However, the policy controls and
definitions are out of scope for this document. definitions are out of scope for this document.
Where an Attesting Environment serves as an endpoint of a Secure Where an Attesting Environment serves as an endpoint of a Secure
Channel used to convey a UCCS, the security assurance required of Channel used to convey a UCCS, the security assurance required of
that Attesting Environment by a Relying Party generally calls for the that Attesting Environment by a Relying Party generally calls for the
Attesting Environment to be implemented using techniques designed to Attesting Environment to be implemented using techniques designed to
provide enhanced protection from an attacker wishing to tamper with provide enhanced protection from an attacker wishing to tamper with
or forge a UCCS originating from that Attesting Environment. A or forge a UCCS originating from that Attesting Environment. A
possible approach might be to implement the Attesting Environment in possible approach might be to implement the Attesting Environment in
a hardened environment, such as a TEE [RFC9397] or a TPM [TPM2]. a hardened environment, such as a TEE [RFC9397] or a TPM [TPM2].
When UCCS emerge from the Secure Channel and into the receiver, the When a UCCS emerges from the Secure Channel and into the receiver,
security properties of the secure channel no longer protect the UCCS, the security properties of the secure channel no longer protect the
which now are subject to the same security properties as any other UCCS, which is now subject to the same security properties as any
unprotected data in the Verifier environment. If the receiver other unprotected data in the Verifier environment. If the receiver
subsequently forwards UCCS, they are treated as though they subsequently forwards UCCS, they are treated as though they
originated within the receiver. originated within the receiver.
The Secure Channel context does not govern fully formed CWTs in the The Secure Channel context does not govern fully formed CWTs in the
same way it governs UCCS. As with EATs (see [RFC9711]) nested in same way it governs UCCS. As with EATs (see [RFC9711]) nested in
other EATs (Section 4.2.18.3 (Nested Tokens) of [RFC9711]), the other EATs (Section 4.2.18.3 (Nested Tokens) of [RFC9711]), the
Secure Channel does not endorse fully formed CWTs transferred through Secure Channel does not endorse fully formed CWTs transferred through
it. Effectively, the COSE envelope of a CWT (or a nested EAT) it. Effectively, the COSE envelope of a CWT (or a nested EAT)
shields the CWT Claims Set from the endorsement of the secure shields the CWT Claims Set from the endorsement of the secure
channel. (Note that an EAT might add a nested UCCS Claim, and this channel. (Note that a nested UCCS Claim might be added to EAT, and
statement does not apply to UCCS nested into UCCS; it only applies to this statement does not apply to UCCS nested into UCCS; it only
fully formed CWTs.) applies to fully formed CWTs.)
5. Considerations for Using UCCS in Other RATS Contexts 5. Considerations for Using UCCS in Other RATS Contexts
This section discusses two additional usage scenarios for UCCS in the This section discusses two additional usage scenarios for UCCS in the
context of RATS. context of RATS.
5.1. Delegated Attestation 5.1. Delegated Attestation
Another usage scenario is that of a sub-Attester that has no signing Another usage scenario is that of a sub-Attester that has no signing
keys (for example, to keep the implementation complexity to a keys (for example, to keep the implementation complexity to a
skipping to change at line 693 skipping to change at line 695
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052, Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022, DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>. <https://www.rfc-editor.org/info/rfc9052>.
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Countersignatures", STD 96, RFC 9338, Countersignatures", STD 96, RFC 9338,
DOI 10.17487/RFC9338, December 2022, DOI 10.17487/RFC9338, December 2022,
<https://www.rfc-editor.org/info/rfc9338>. <https://www.rfc-editor.org/info/rfc9338>.
[TPM2] Trusted Computing Group, "Trusted Platform Module Library [TPM2] Trusted Computing Group, "Trusted Platform Module 2.0
Specification", Family "2.0", Level 00, Revision 01.59, Library", Version 184, March 2025,
2019. <https://trustedcomputinggroup.org/resource/tpm-library-
specification/>.
Appendix A. CDDL Appendix A. CDDL
The Concise Data Definition Language (CDDL), as defined in [RFC8610] The Concise Data Definition Language (CDDL), as defined in [RFC8610]
and [RFC9165], provides an easy and unambiguous way to express and [RFC9165], provides an easy and unambiguous way to express
structures for protocol messages and data formats that use CBOR or structures for protocol messages and data formats that use CBOR or
JSON. JSON.
[RFC8392] does not define CDDL for CWT Claims Sets. [RFC8392] does not define CDDL for CWT Claims Sets.
 End of changes. 9 change blocks. 
22 lines changed or deleted 25 lines changed or added

This html diff was produced by rfcdiff 1.48.