idnits 2.17.1 draft-ietf-rats-uccs-02.txt: -(9): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (12 January 2022) is 828 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCthis' is mentioned on line 296, but not defined == Missing Reference: 'IESG' is mentioned on line 554, but not defined ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-14 == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-11 == Outdated reference: A later version (-19) exists of draft-ietf-teep-architecture-15 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS Working Group H. Birkholz 3 Internet-Draft Fraunhofer SIT 4 Intended status: Standards Track J. O'Donoghue 5 Expires: 16 July 2022 Qualcomm Technologies Inc. 6 N. Cam-Winget 7 Cisco Systems 8 C. Bormann 9 Universität Bremen TZI 10 12 January 2022 12 A CBOR Tag for Unprotected CWT Claims Sets 13 draft-ietf-rats-uccs-02 15 Abstract 17 CBOR Web Token (CWT, RFC 8392) Claims Sets sometimes do not need the 18 protection afforded by wrapping them into COSE, as is required for a 19 true CWT. This specification defines a CBOR tag for such unprotected 20 CWT Claims Sets (UCCS) and discusses conditions for its proper use. 22 // The present version (-01) has a few editorial improvements over 23 // -00 and attempts to address points from Thomas Fossati's 24 // 2021-03-16 review, for further discussion at IETF 111. 26 About This Document 28 This note is to be removed before publishing as an RFC. 30 Status information for this document may be found at 31 https://datatracker.ietf.org/doc/draft-ietf-rats-uccs/. 33 Discussion of this document takes place on the Remote ATtestation 34 ProcedureS (rats) Working Group mailing list (mailto:rats@ietf.org), 35 which is archived at https://mailarchive.ietf.org/arch/browse/rats/. 37 Source for this draft and an issue tracker can be found at 38 https://github.com/ietf-rats-wg/draft-ietf-rats-uccs. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on 16 July 2022. 57 Copyright Notice 59 Copyright (c) 2022 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 64 license-info) in effect on the date of publication of this document. 65 Please review these documents carefully, as they describe your rights 66 and restrictions with respect to this document. Code Components 67 extracted from this document must include Revised BSD License text as 68 described in Section 4.e of the Trust Legal Provisions and are 69 provided without warranty as described in the Revised BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 4 76 3. Characteristics of a Secure Channel . . . . . . . . . . . . . 4 77 3.1. UCCS and Remote ATtestation procedureS (RATS) . . . . . . 5 78 3.2. Privacy Preserving Channels . . . . . . . . . . . . . . . 6 79 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 81 5.1. General Considerations . . . . . . . . . . . . . . . . . 7 82 5.2. AES-CBC_MAC . . . . . . . . . . . . . . . . . . . . . . . 8 83 5.3. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 5.4. AES-CCM . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 5.5. ChaCha20 and Poly1305 . . . . . . . . . . . . . . . . . . 9 86 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 87 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 88 6.2. Informative References . . . . . . . . . . . . . . . . . 10 89 Appendix A. CDDL . . . . . . . . . . . . . . . . . . . . . . . . 11 90 Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . 13 91 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 94 1. Introduction 96 A CBOR Web Token (CWT) as specified by [RFC8392] is always wrapped in 97 a CBOR Object Signing and Encryption (COSE, [RFC8152]) envelope. 98 COSE provides -- amongst other things -- the end-to-end data origin 99 authentication and integrity protection employed by RFC 8392 and 100 optional encryption for CWTs. Under the right circumstances 101 (Section 3), though, a signature providing proof for authenticity and 102 integrity can be provided through the transfer protocol and thus 103 omitted from the information in a CWT without compromising the 104 intended goal of authenticity and integrity. In other words, if 105 communicating parties have a pre-existing security association they 106 can reuse it to provide authenticity and integrity for their 107 messages, enabling the basic principle of using resources 108 parsimoniously. Specifically, if a mutually Secured Channel is 109 established between two remote peers, and if that Secure Channel 110 provides the required properties (as discussed below), it is possible 111 to omit the protection provided by COSE, creating a use case for 112 unprotected CWT Claims Sets. Similarly, if there is one-way 113 authentication, the party that did not authenticate may be in a 114 position to send authentication information through this channel that 115 allows the already authenticated party to authenticate the other 116 party. 118 This specification allocates a CBOR tag to mark Unprotected CWT 119 Claims Sets (UCCS) as such and discusses conditions for its proper 120 use in the scope of Remote ATtestation procedureS (RATS) and the 121 conveyance of Evidence from an Attester to a Verifier. 123 This specification does not change [RFC8392]: A true CWT does not 124 make use of the tag allocated here; the UCCS tag is an alternative to 125 using COSE protection and a CWT tag. Consequently, within the well- 126 defined scope of a secured channel, it can be acceptable and economic 127 to use the contents of a CWT without its COSE container and tag it 128 with a UCCS CBOR tag for further processing within that scope -- or 129 to use the contents of a UCCS CBOR tag for building a CWT to be 130 signed by some entity that can vouch for those contents. 132 1.1. Terminology 134 The term Claim is used as in [RFC7519]. 136 The terms Claim Key, Claim Value, and CWT Claims Set are used as in 137 [RFC8392]. 139 The terms Attester, Attesting Environment and Verifier are used as in 140 [I-D.ietf-rats-architecture]. 142 UCCS: Unprotected CWT Claims Set(s); CBOR map(s) of Claims as 143 defined by the CWT Claims Registry that are composed of pairs of 144 Claim Keys and Claim Values. 146 Secure Channel: A protected communication channel between two peers 147 that can ensure the same qualities associated for UCCS conveyance 148 as CWT conveyance without any additional protection. 150 All terms referenced or defined in this section are capitalized in 151 the remainder of this document. 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 155 "OPTIONAL" in this document are to be interpreted as described in 156 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 157 capitals, as shown here. 159 2. Example Use Cases 161 Use cases involving the conveyance of Claims, in particular, remote 162 attestation procedures (RATS, see [I-D.ietf-rats-architecture]) 163 require a standardized data definition and encoding format that can 164 be transferred and transported using different communication 165 channels. As these are Claims, [RFC8392] is a suitable format. 166 However, the way these Claims are secured depends on the deployment, 167 the security capabilities of the device, as well as their software 168 stack. For example, a Claim may be securely stored and conveyed 169 using a device's Trusted Execution Environment (TEE, see 170 [I-D.ietf-teep-architecture]) or especially in some resource 171 constrained environments, the same process that provides the secure 172 communication transport is also the delegate to compose the Claim to 173 be conveyed. Whether it is a transfer or transport, a Secure Channel 174 is presumed to be used for conveying such UCCS. The following 175 sections further describe the RATS usage scenario and corresponding 176 requirements for UCCS deployment. 178 3. Characteristics of a Secure Channel 180 A Secure Channel for the conveyance of UCCS needs to provide the 181 security properties that would otherwise be provided by COSE for a 182 CWT. In this regard, UCCS is similar in security considerations to 183 JWTs [RFC8725] using the algorithm "none". RFC 8725 states: 185 | [...] if a JWT is cryptographically protected end-to-end by a 186 | transport layer, such as TLS using cryptographically current 187 | algorithms, there may be no need to apply another layer of 188 | cryptographic protections to the JWT. In such cases, the use of 189 | the "none" algorithm can be perfectly acceptable. 191 The security considerations discussed, e.g., in Sections 2.1, 3.1, 192 and 3.2 of [RFC8725] apply in an analogous way to the use of UCCS as 193 elaborated on in this document. 195 Secure Channels are often set up in a handshake protocol that 196 mutually derives a session key, where the handshake protocol 197 establishes the (identity and thus) authenticity of one or both ends 198 of the communication. The session key can then be used to provide 199 confidentiality and integrity of the transfer of information inside 200 the Secure Channel. A well-known example of a such a Secure Channel 201 setup protocol is the TLS [RFC8446] handshake; the TLS record 202 protocol can then be used for secure conveyance. 204 As UCCS were initially created for use in Remote ATtestation 205 procedureS (RATS) Secure Channels, the following subsection provides 206 a discussion of their use in these channels. Where other 207 environments are intended to be used to convey UCCS, similar 208 considerations need to be documented before UCCS can be used. 210 3.1. UCCS and Remote ATtestation procedureS (RATS) 212 For the purposes of this section, the Verifier is the receiver of the 213 UCCS and the Attester is the provider of the UCCS. 215 Secure Channels can be transient in nature. For the purposes of this 216 specification, the mechanisms used to establish a Secure Channel are 217 out of scope. 219 As a minimum requirement in the scope of RATS Claims, the Verifier 220 MUST authenticate the Attester as part of the establishment of the 221 Secure Channel. Furthermore, the channel MUST provide integrity of 222 the communication from the Attester to the Verifier. If 223 confidentiality is also required, the receiving side needs to be 224 authenticated as well; this can be achieved if the Verifier and the 225 Attester mutually authenticate when establishing the Secure Channel. 227 The extent to which a Secure Channel can provide assurances that UCCS 228 originate from a trustworthy attesting environment depends on the 229 characteristics of both the cryptographic mechanisms used to 230 establish the channel and the characteristics of the attesting 231 environment itself. 233 A Secure Channel established or maintained using weak cryptography 234 may not provide the assurance required by a relying party of the 235 authenticity and integrity of the UCCS. 237 Ultimately, it is up to the Verifier's policy to determine whether to 238 accept a UCCS from the Attester and to the type of Secure Channel it 239 must negotiate. While the security considerations of the 240 cryptographic algorithms used are similar to COSE, the considerations 241 of the secure channel should also adhere to the policy configured at 242 each of the Attester and the Verifier. However, the policy controls 243 and definitions are out of scope for this document. 245 Where the security assurance required of an attesting environment by 246 a relying party requires it, the attesting environment may be 247 implemented using techniques designed to provide enhanced protection 248 from an attacker wishing to tamper with or forge UCCS. A possible 249 approach might be to implement the attesting environment in a 250 hardened environment such as a TEE [I-D.ietf-teep-architecture] or a 251 TPM [TPM2]. 253 When UCCS emerge from the Secure Channel and into the Verifier, the 254 security properties of the Secure Channel no longer apply and UCCS 255 have the same properties as any other unprotected data in the 256 Verifier environment. If the Verifier subsequently forwards UCCS, 257 they are treated as though they originated within the Verifier. 259 As with EATs nested in other EATs (Section 3.20.1.2 of 260 [I-D.ietf-rats-eat]), the Secure Channel does not endorse fully 261 formed CWTs transferred through it. Effectively, the COSE envelope 262 of a CWT shields the CWT Claims Set from the endorsement of the 263 Secure Channel. (Note that EAT might add a nested UCCS Claim, and 264 this statement does not apply to UCCS nested into UCCS, only to fully 265 formed CWTs) 267 3.2. Privacy Preserving Channels 269 A Secure Channel which preserves the privacy of the Attester may 270 provide security properties equivalent to COSE, but only inside the 271 life-span of the session established. In general, a Verifier cannot 272 correlate UCCS received in different sessions from the same attesting 273 environment based on the cryptographic mechanisms used when a privacy 274 preserving Secure Channel is employed. 276 In the case of a Remote Attestation, the attester must consider 277 whether any UCCS it returns over a privacy preserving Secure Channel 278 compromises the privacy in unacceptable ways. As an example, the use 279 of the EAT UEID [I-D.ietf-rats-eat] Claim in UCCS over a privacy 280 preserving Secure Channel allows a verifier to correlate UCCS from a 281 single attesting environment across many Secure Channel sessions. 282 This may be acceptable in some use-cases (e.g. if the attesting 283 environment is a physical sensor in a factory) and unacceptable in 284 others (e.g. if the attesting environment is a device belonging to a 285 child). 287 4. IANA Considerations 289 In the registry [IANA.cbor-tags], IANA is requested to allocate the 290 tag in Table 1 from the FCFS space, with the present document as the 291 specification reference. 293 +========+===========+======================================+ 294 | Tag | Data Item | Semantics | 295 +========+===========+======================================+ 296 | TBD601 | map | Unprotected CWT Claims Set [RFCthis] | 297 +--------+-----------+--------------------------------------+ 299 Table 1: Values for Tags 301 5. Security Considerations 303 The security considerations of [RFC8949] apply. The security 304 considerations of [RFC8392] need to be applied analogously, replacing 305 the role of COSE with that of the Secured Channel. 307 Section 3 discusses security considerations for Secure Channels, in 308 which UCCS might be used. This document provides the CBOR tag 309 definition for UCCS and a discussion on security consideration for 310 the use of UCCS in Remote ATtestation procedureS (RATS). Uses of 311 UCCS outside the scope of RATS are not covered by this document. The 312 UCCS specification - and the use of the UCCS CBOR tag, 313 correspondingly - is not intended for use in a scope where a scope- 314 specific security consideration discussion has not been conducted, 315 vetted and approved for that use. 317 5.1. General Considerations 319 Implementations of Secure Channels are often separate from the 320 application logic that has security requirements on them. Similar 321 security considerations to those described in 322 [I-D.ietf-cose-rfc8152bis-struct] for obtaining the required levels 323 of assurance include: 325 * Implementations need to provide sufficient protection for private 326 or secret key material used to establish or protect the Secure 327 Channel. 329 * Using a key for more than one algorithm can leak information about 330 the key and is not recommended. 332 * An algorithm used to establish or protect the Secure Channel may 333 have limits on the number of times that a key can be used without 334 leaking information about the key. 336 The Verifier needs to ensure that the management of key material used 337 establish or protect the Secure Channel is acceptable. This may 338 include factors such as: 340 * Ensuring that any permissions associated with key ownership are 341 respected in the establishment of the Secure Channel. 343 * Cryptographic algorithms are used appropriately. 345 * Key material is used in accordance with any usage restrictions 346 such as freshness or algorithm restrictions. 348 * Ensuring that appropriate protections are in place to address 349 potential traffic analysis attacks. 351 5.2. AES-CBC_MAC 353 * A given key should only be used for messages of fixed or known 354 length. 356 * Different keys should be used for authentication and encryption 357 operations. 359 * A mechanism to ensure that IV cannot be modified is required. 361 Section 3.2.1 of [I-D.ietf-cose-rfc8152bis-algs] contains a detailed 362 explanation of these considerations. 364 5.3. AES-GCM 366 * The key and nonce pair are unique for every encrypted message. 368 * The maximum number of messages to be encrypted for a given key is 369 not exceeded. 371 Section 4.1.1 of [I-D.ietf-cose-rfc8152bis-algs] contains a detailed 372 explanation of these considerations. 374 5.4. AES-CCM 376 * The key and nonce pair are unique for every encrypted message. 378 * The maximum number of messages to be encrypted for a given block 379 cipher is not exceeded. 381 * The number of messages both successfully and unsuccessfully 382 decrypted is used to determine when rekeying is required. 384 Section 4.2.1 of [I-D.ietf-cose-rfc8152bis-algs] contains a detailed 385 explanation of these considerations. 387 5.5. ChaCha20 and Poly1305 389 * The nonce is unique for every encrypted message. 391 * The number of messages both successfully and unsuccessfully 392 decrypted is used to determine when rekeying is required. 394 Section 4.3.1 of [I-D.ietf-cose-rfc8152bis-algs] contains a detailed 395 explanation of these considerations. 397 6. References 399 6.1. Normative References 401 [IANA.cbor-tags] 402 IANA, "Concise Binary Object Representation (CBOR) Tags", 403 . 405 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 406 Requirement Levels", BCP 14, RFC 2119, 407 DOI 10.17487/RFC2119, March 1997, 408 . 410 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 411 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 412 . 414 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 415 RFC 8152, DOI 10.17487/RFC8152, July 2017, 416 . 418 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 419 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 420 May 2017, . 422 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 423 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 424 May 2018, . 426 [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best 427 Current Practices", BCP 225, RFC 8725, 428 DOI 10.17487/RFC8725, February 2020, 429 . 431 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 432 Representation (CBOR)", STD 94, RFC 8949, 433 DOI 10.17487/RFC8949, December 2020, 434 . 436 6.2. Informative References 438 [I-D.ietf-cose-rfc8152bis-algs] 439 Schaad, J., "CBOR Object Signing and Encryption (COSE): 440 Initial Algorithms", Work in Progress, Internet-Draft, 441 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 442 . 445 [I-D.ietf-cose-rfc8152bis-struct] 446 Schaad, J., "CBOR Object Signing and Encryption (COSE): 447 Structures and Process", Work in Progress, Internet-Draft, 448 draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, 449 . 452 [I-D.ietf-rats-architecture] 453 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 454 W. Pan, "Remote Attestation Procedures Architecture", Work 455 in Progress, Internet-Draft, draft-ietf-rats-architecture- 456 14, 9 December 2021, . 459 [I-D.ietf-rats-eat] 460 Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity 461 Attestation Token (EAT)", Work in Progress, Internet- 462 Draft, draft-ietf-rats-eat-11, 24 October 2021, 463 . 466 [I-D.ietf-teep-architecture] 467 Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, 468 "Trusted Execution Environment Provisioning (TEEP) 469 Architecture", Work in Progress, Internet-Draft, draft- 470 ietf-teep-architecture-15, 12 July 2021, 471 . 474 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 475 RFC 6749, DOI 10.17487/RFC6749, October 2012, 476 . 478 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 479 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 480 . 482 [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., 483 and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, 484 DOI 10.17487/RFC8693, January 2020, 485 . 487 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 488 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 489 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 490 2020, . 492 [TPM2] "Trusted Platform Module Library Specification, Family 493 “2.0”, Level 00, Revision 01.59 ed., Trusted Computing 494 Group", 2019. 496 Appendix A. CDDL 498 [RFC8392] does not define CDDL for CWT Claims sets. 500 This specification proposes using the definitions in Figure 1 for the 501 claims set defined in [RFC8392]. Note that these definitions have 502 been built such that they also can describe [RFC7519] claims sets by 503 disabling feature "cbor" and enabling feature "json", but this 504 flexibility is not the subject of the present specification. 506 Claims-Set = { 507 * $$Claims-Set-Claims 508 * Claim-Label .feature "extended-claims-label" => any 509 } 510 Claim-Label = int / text 511 string-or-uri = text 513 $$Claims-Set-Claims //= ( iss-claim-label => string-or-uri ) 514 $$Claims-Set-Claims //= ( sub-claim-label => string-or-uri ) 515 $$Claims-Set-Claims //= ( aud-claim-label => string-or-uri ) 516 $$Claims-Set-Claims //= ( exp-claim-label => ~time ) 517 $$Claims-Set-Claims //= ( nbf-claim-label => ~time ) 518 $$Claims-Set-Claims //= ( iat-claim-label => ~time ) 519 $$Claims-Set-Claims //= ( cti-claim-label => bytes ) 521 iss-claim-label = JC<"iss", 1> 522 sub-claim-label = JC<"sub", 2> 523 aud-claim-label = JC<"aud", 3> 524 exp-claim-label = JC<"exp", 4> 525 nbf-claim-label = JC<"nbf", 5> 526 iat-claim-label = JC<"iat", 6> 527 cti-claim-label = CBOR-ONLY<7> ; jti in JWT: different name and text 529 JSON-ONLY = J .feature "json" 530 CBOR-ONLY = C .feature "cbor" 531 JC = JSON-ONLY / CBOR-ONLY 533 Figure 1: CDDL definition for Claims-Set 535 Specifications that define additional claims should also supply 536 additions to the $$Claims-Set-Claims socket, e.g.: 538 ; [RFC8747] 539 $$Claims-Set-Claims //= ( 8: CWT-cnf ) ; cnf 540 CWT-cnf = { 541 (1: CWT-COSE-Key) // 542 (2: CWT-Encrypted_COSE_Key) // 543 (3: CWT-kid) 544 } 546 CWT-COSE-Key = COSE_Key 547 CWT-Encrypted_COSE_Key = COSE_Encrypt / COSE_Encrypt0 548 CWT-kid = bytes 550 ; [RFC8693] 551 $$Claims-Set-Claims //= ( 9: CWT-scope ) ; scope 552 ; TO DO: understand what this means: 553 ; scope The scope of an access token as defined in [RFC6749]. 554 ; scope 9 byte string or text string [IESG] [RFC8693, Section 4.2] 555 CWT-scope = bytes / text 557 ; [RFC-ietf-ace-oauth-authz-45, Section 5.10] 558 $$Claims-Set-Claims //= ( 38: CWT-ace-profile ) ; ace_profile 559 CWT-ace-profile = $CWT-ACE-Profiles / 560 int .feature "ace_profile-extend" 561 ; fill in from IANA registry 562 ; https://www.iana.org/assignments/ace/ace.xhtml#ace-profiles : 563 $CWT-ACE-Profiles /= 1 ; coap_dtls 565 $$Claims-Set-Claims //= ( 39: CWT-cnonce ) ; cnonce 566 CWT-cnonce = bytes 568 $$Claims-Set-Claims //= ( 40: CWT-exi ) ; exi 569 CWT-exi = uint ; in seconds (5.10.3) 571 ;;; insert CDDL from 9052-to-be to complete these CDDL definitions. 573 Appendix B. Example 575 The example CWT Claims Set from Appendix A.1 of [RFC8392] can be 576 turned into an UCCS by enclosing it with a tag number TBD601: 578 ( 579 { 580 / iss / 1: "coap://as.example.com", 581 / sub / 2: "erikw", 582 / aud / 3: "coap://light.example.com", 583 / exp / 4: 1444064944, 584 / nbf / 5: 1443944944, 585 / iat / 6: 1443944944, 586 / cti / 7: h'0b71' 587 } 588 ) 590 Acknowledgements 592 Laurence Lundblade suggested some improvements to the CDDL. 594 Authors' Addresses 596 Henk Birkholz 597 Fraunhofer SIT 598 Rheinstrasse 75 599 64295 Darmstadt 600 Germany 602 Email: henk.birkholz@sit.fraunhofer.de 604 Jeremy O'Donoghue 605 Qualcomm Technologies Inc. 606 279 Farnborough Road 607 Farnborough 608 GU14 7LS 609 United Kingdom 611 Email: jodonogh@qti.qualcomm.com 613 Nancy Cam-Winget 614 Cisco Systems 615 3550 Cisco Way 616 San Jose, CA 95134 617 United States of America 619 Email: ncamwing@cisco.com 620 Carsten Bormann 621 Universität Bremen TZI 622 Postfach 330440 623 D-28359 Bremen 624 Germany 626 Phone: +49-421-218-63921 627 Email: cabo@tzi.org