idnits 2.17.1 draft-ietf-rats-eat-08.txt: 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 18 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 04, 2021) is 1170 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'CoSWID' -- Possible downref: Non-RFC (?) normative reference: ref. 'EAN-13' -- Possible downref: Non-RFC (?) normative reference: ref. 'OpenIDConnectCore' ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) -- Possible downref: Non-RFC (?) normative reference: ref. 'WGS84' Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS Working Group G. Mandyam 3 Internet-Draft Qualcomm Technologies Inc. 4 Intended status: Standards Track L. Lundblade 5 Expires: August 8, 2021 Security Theory LLC 6 M. Ballesteros 7 J. O'Donoghue 8 Qualcomm Technologies Inc. 9 February 04, 2021 11 The Entity Attestation Token (EAT) 12 draft-ietf-rats-eat-08 14 Abstract 16 An Entity Attestation Token (EAT) provides a signed (attested) set of 17 claims that describe state and characteristics of an entity, 18 typically a device like a phone or an IoT device. These claims are 19 used by a relying party to determine how much it wishes to trust the 20 entity. 22 An EAT is either a CWT or JWT with some attestation-oriented claims. 23 To a large degree, all this document does is extend CWT and JWT. 25 Contributing 27 TBD 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 8, 2021. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. CWT, JWT and UCCS . . . . . . . . . . . . . . . . . . . . 5 65 1.2. CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 1.3. Entity Overview . . . . . . . . . . . . . . . . . . . . . 6 67 1.4. EAT Operating Models . . . . . . . . . . . . . . . . . . 6 68 1.5. What is Not Standardized . . . . . . . . . . . . . . . . 8 69 1.5.1. Transmission Protocol . . . . . . . . . . . . . . . . 8 70 1.5.2. Signing Scheme . . . . . . . . . . . . . . . . . . . 8 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 3. The Claims . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 3.1. Token ID Claim (cti and jti) . . . . . . . . . . . . . . 10 74 3.2. Timestamp claim (iat) . . . . . . . . . . . . . . . . . . 10 75 3.3. Nonce Claim (nonce) . . . . . . . . . . . . . . . . . . . 10 76 3.3.1. nonce CDDL . . . . . . . . . . . . . . . . . . . . . 11 77 3.4. Universal Entity ID Claim (ueid) . . . . . . . . . . . . 11 78 3.4.1. ueid CDDL . . . . . . . . . . . . . . . . . . . . . . 13 79 3.5. Origination Claim (origination) . . . . . . . . . . . . . 13 80 3.5.1. origination CDDL . . . . . . . . . . . . . . . . . . 14 81 3.6. OEM Identification by IEEE (oemid) . . . . . . . . . . . 14 82 3.6.1. oemid CDDL . . . . . . . . . . . . . . . . . . . . . 14 83 3.7. Hardware Version Claims (hardware-version-claims) . . . . 14 84 3.8. Software Description and Version . . . . . . . . . . . . 16 85 3.9. The Security Level Claim (security-level) . . . . . . . . 16 86 3.9.1. security-level CDDL . . . . . . . . . . . . . . . . . 17 87 3.10. Secure Boot Claim (secure-boot) . . . . . . . . . . . . . 17 88 3.10.1. secure-boot CDDL . . . . . . . . . . . . . . . . . . 18 89 3.11. Debug Status Claim (debug-status) . . . . . . . . . . . . 18 90 3.11.1. Enabled . . . . . . . . . . . . . . . . . . . . . . 19 91 3.11.2. Disabled . . . . . . . . . . . . . . . . . . . . . . 19 92 3.11.3. Disabled Since Boot . . . . . . . . . . . . . . . . 19 93 3.11.4. Disabled Permanently . . . . . . . . . . . . . . . . 19 94 3.11.5. Disabled Fully and Permanently . . . . . . . . . . . 19 95 3.11.6. debug-status CDDL . . . . . . . . . . . . . . . . . 20 96 3.12. Including Keys . . . . . . . . . . . . . . . . . . . . . 20 97 3.13. The Location Claim (location) . . . . . . . . . . . . . . 21 98 3.13.1. location CDDL . . . . . . . . . . . . . . . . . . . 21 99 3.14. The Uptime Claim (uptime) . . . . . . . . . . . . . . . . 22 100 3.14.1. uptime CDDL . . . . . . . . . . . . . . . . . . . . 22 101 3.14.2. The Boot Seed Claim (boot-seed) . . . . . . . . . . 22 102 3.15. The Intended Use Claim (intended-use) . . . . . . . . . . 23 103 3.15.1. intended-use CDDL . . . . . . . . . . . . . . . . . 23 104 3.16. The Profile Claim (profile) . . . . . . . . . . . . . . . 24 105 3.17. The Submodules Part of a Token (submods) . . . . . . . . 24 106 3.17.1. Two Types of Submodules . . . . . . . . . . . . . . 25 107 3.17.1.1. Non-token Submodules . . . . . . . . . . . . . . 25 108 3.17.1.2. Nested EATs . . . . . . . . . . . . . . . . . . 25 109 3.17.1.3. Unsecured JWTs and UCCS Tokens as Submodules . . 26 110 3.17.2. No Inheritance . . . . . . . . . . . . . . . . . . . 27 111 3.17.3. Security Levels . . . . . . . . . . . . . . . . . . 27 112 3.17.4. Submodule Names . . . . . . . . . . . . . . . . . . 27 113 3.17.5. submods CDDL . . . . . . . . . . . . . . . . . . . . 27 114 4. Endorsements and Verification Keys . . . . . . . . . . . . . 28 115 5. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 28 116 5.1. List of Profile Issues . . . . . . . . . . . . . . . . . 29 117 5.1.1. Use of JSON, CBOR or both . . . . . . . . . . . . . . 29 118 5.1.2. CBOR Map and Array Encoding . . . . . . . . . . . . . 29 119 5.1.3. CBOR String Encoding . . . . . . . . . . . . . . . . 29 120 5.1.4. COSE/JOSE Protection . . . . . . . . . . . . . . . . 29 121 5.1.5. COSE/JOSE Algorithms . . . . . . . . . . . . . . . . 30 122 5.1.6. Verification Key Identification . . . . . . . . . . . 30 123 5.1.7. Endorsement Identification . . . . . . . . . . . . . 30 124 5.1.8. Required Claims . . . . . . . . . . . . . . . . . . . 30 125 5.1.9. Prohibited Claims . . . . . . . . . . . . . . . . . . 30 126 5.1.10. Additional Claims . . . . . . . . . . . . . . . . . . 31 127 5.1.11. Refined Claim Definition . . . . . . . . . . . . . . 31 128 5.1.12. CBOR Tags . . . . . . . . . . . . . . . . . . . . . . 31 129 6. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 31 130 6.1. Common CDDL Types . . . . . . . . . . . . . . . . . . . . 31 131 6.2. CDDL for CWT-defined Claims . . . . . . . . . . . . . . . 31 132 6.3. JSON . . . . . . . . . . . . . . . . . . . . . . . . . . 32 133 6.3.1. JSON Labels . . . . . . . . . . . . . . . . . . . . . 32 134 6.3.2. JSON Interoperability . . . . . . . . . . . . . . . . 33 135 6.4. CBOR . . . . . . . . . . . . . . . . . . . . . . . . . . 33 136 6.4.1. CBOR Interoperability . . . . . . . . . . . . . . . . 33 137 6.4.1.1. EAT Constrained Device Serialization . . . . . . 33 138 6.5. Collected CDDL . . . . . . . . . . . . . . . . . . . . . 34 139 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 140 7.1. Reuse of CBOR Web Token (CWT) Claims Registry . . . . . . 40 141 7.2. Claim Characteristics . . . . . . . . . . . . . . . . . . 40 142 7.2.1. Interoperability and Relying Party Orientation . . . 41 143 7.2.2. Operating System and Technology Neutral . . . . . . . 41 144 7.2.3. Security Level Neutral . . . . . . . . . . . . . . . 41 145 7.2.4. Reuse of Extant Data Formats . . . . . . . . . . . . 42 146 7.2.5. Proprietary Claims . . . . . . . . . . . . . . . . . 42 147 7.3. Claims Registered by This Document . . . . . . . . . . . 42 148 7.3.1. Claims for Early Assignment . . . . . . . . . . . . . 43 149 7.3.2. To be Assigned Claims . . . . . . . . . . . . . . . . 45 150 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 45 151 8.1. UEID Privacy Considerations . . . . . . . . . . . . . . . 45 152 8.2. Location Privacy Considerations . . . . . . . . . . . . . 46 153 9. Security Considerations . . . . . . . . . . . . . . . . . . . 46 154 9.1. Key Provisioning . . . . . . . . . . . . . . . . . . . . 47 155 9.1.1. Transmission of Key Material . . . . . . . . . . . . 47 156 9.2. Transport Security . . . . . . . . . . . . . . . . . . . 47 157 9.3. Multiple EAT Consumers . . . . . . . . . . . . . . . . . 48 158 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 159 10.1. Normative References . . . . . . . . . . . . . . . . . . 48 160 10.2. Informative References . . . . . . . . . . . . . . . . . 50 161 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 53 162 A.1. Very Simple EAT . . . . . . . . . . . . . . . . . . . . . 53 163 A.2. Example with Submodules, Nesting and Security Levels . . 53 164 Appendix B. UEID Design Rationale . . . . . . . . . . . . . . . 53 165 B.1. Collision Probability . . . . . . . . . . . . . . . . . . 54 166 B.2. No Use of UUID . . . . . . . . . . . . . . . . . . . . . 56 167 Appendix C. Changes from Previous Drafts . . . . . . . . . . . . 57 168 C.1. From draft-rats-eat-01 . . . . . . . . . . . . . . . . . 57 169 C.2. From draft-mandyam-rats-eat-00 . . . . . . . . . . . . . 57 170 C.3. From draft-ietf-rats-eat-01 . . . . . . . . . . . . . . . 57 171 C.4. From draft-ietf-rats-eat-02 . . . . . . . . . . . . . . . 57 172 C.5. From draft-ietf-rats-eat-03 . . . . . . . . . . . . . . . 58 173 C.6. From draft-ietf-rats-eat-04 . . . . . . . . . . . . . . . 58 174 C.7. From draft-ietf-rats-05 . . . . . . . . . . . . . . . . . 58 175 C.8. From draft-ietf-rats-06 . . . . . . . . . . . . . . . . . 59 176 C.9. From draft-ietf-rats-07 . . . . . . . . . . . . . . . . . 59 177 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 179 1. Introduction 181 Remote device attestation is a fundamental service that allows a 182 remote device such as a mobile phone, an Internet-of-Things (IoT) 183 device, or other endpoint to prove itself to a relying party, a 184 server or a service. This allows the relying party to know some 185 characteristics about the device and decide whether it trusts the 186 device. 188 Remote attestation is a fundamental service that can underlie other 189 protocols and services that need to know about the trustworthiness of 190 the device before proceeding. One good example is biometric 191 authentication where the biometric matching is done on the device. 192 The relying party needs to know that the device is one that is known 193 to do biometric matching correctly. Another example is content 194 protection where the relying party wants to know the device will 195 protect the data. This generalizes on to corporate enterprises that 196 might want to know that a device is trustworthy before allowing 197 corporate data to be accessed by it. 199 The notion of attestation here is large and may include, but is not 200 limited to the following: 202 o Proof of the make and model of the device hardware (HW) 204 o Proof of the make and model of the device processor, particularly 205 for security-oriented chips 207 o Measurement of the software (SW) running on the device 209 o Configuration and state of the device 211 o Environmental characteristics of the device such as its GPS 212 location 214 TODO: mention use for Attestation Evidence and Results. 216 1.1. CWT, JWT and UCCS 218 For flexibility and ease of imlpementation in a wide variety of 219 environments, EATs can be either CBOR [RFC8949] or JSON [ECMAScript] 220 format. This specification simultaneously describes both formats. 222 An EAT is either a CWT as defined in [RFC8392], a UCCS as defined in 223 [UCCS.Draft], or a JWT as defined in [RFC7519]. This specification 224 extends those specifications with additional claims for attestation. 226 The identification of a protocol element as an EAT, whether CBOR or 227 JSON format, follows the general conventions used by CWT, JWT and 228 UCCS. Largely this depends on the protocol carrying the EAT. In 229 some cases it may be by content type (e.g., MIME type). In other 230 cases it may be through use of CBOR tags. There is no fixed 231 mechanism across all use cases. 233 1.2. CDDL 235 This specification uses CDDL, [RFC8610], as the primary formalism to 236 define each claim. The implementor then interprets the CDDL to come 237 to either the CBOR [RFC8949] or JSON [ECMAScript] representation. In 238 the case of JSON, Appendix E of [RFC8610] is followed. Additional 239 rules are given in Section 6.3.2 of this document where Appendix E is 240 insufficient. (Note that this is not to define a general means to 241 translate between CBOR and JSON, but only to define enough such that 242 the claims defined in this document can be rendered unambiguously in 243 JSON). 245 The CWT specification was authored before CDDL was available and did 246 not use it. This specification includes a CDDL definition of most of 247 what is described in [RFC8392]. 249 1.3. Entity Overview 251 An "entity" can be any device or device subassembly ("submodule") 252 that can generate its own attestation in the form of an EAT. The 253 attestation should be cryptographically verifiable by the EAT 254 consumer. An EAT at the device-level can be composed of several 255 submodule EAT's. It is assumed that any entity that can create an 256 EAT does so by means of a dedicated root-of-trust (RoT). 258 Modern devices such as a mobile phone have many different execution 259 environments operating with different security levels. For example, 260 it is common for a mobile phone to have an "apps" environment that 261 runs an operating system (OS) that hosts a plethora of downloadable 262 apps. It may also have a TEE (Trusted Execution Environment) that is 263 distinct, isolated, and hosts security-oriented functionality like 264 biometric authentication. Additionally, it may have an eSE (embedded 265 Secure Element) - a high security chip with defenses against HW 266 attacks that can serve as a RoT. This device attestation format 267 allows the attested data to be tagged at a security level from which 268 it originates. In general, any discrete execution environment that 269 has an identifiable security level can be considered an entity. 271 1.4. EAT Operating Models 273 TODO: Rewrite (or eliminate) this section in light of the RATS 274 architecture draft. 276 At least the following three participants exist in all EAT operating 277 models. Some operating models have additional participants. 279 The Entity. This is the phone, the IoT device, the sensor, the sub- 280 assembly or such that the attestation provides information about. 282 The Manufacturer. The company that made the entity. This may be a 283 chip vendor, a circuit board module vendor or a vendor of finished 284 consumer products. 286 The Relying Party. The server, service or company that makes use of 287 the information in the EAT about the entity. 289 In all operating models, the manufacturer provisions some secret 290 attestation key material (AKM) into the entity during manufacturing. 291 This might be during the manufacturer of a chip at a fabrication 292 facility (fab) or during final assembly of a consumer product or any 293 time in between. This attestation key material is used for signing 294 EATs. 296 In all operating models, hardware and/or software on the entity 297 create an EAT of the format described in this document. The EAT is 298 always signed by the attestation key material provisioned by the 299 manufacturer. 301 In all operating models, the relying party must end up knowing that 302 the signature on the EAT is valid and consistent with data from 303 claims in the EAT. This can happen in many different ways. Here are 304 some examples. 306 o The EAT is transmitted to the relying party. The relying party 307 gets corresponding key material (e.g. a root certificate) from the 308 manufacturer. The relying party performs the verification. 310 o The EAT is transmitted to the relying party. The relying party 311 transmits the EAT to a verification service offered by the 312 manufacturer. The server returns the validated claims. 314 o The EAT is transmitted directly to a verification service, perhaps 315 operated by the manufacturer or perhaps by another party. It 316 verifies the EAT and makes the validated claims available to the 317 relying party. It may even modify the claims in some way and re- 318 sign the EAT (with a different signing key). 320 All these operating models are supported and there is no preference 321 of one over the other. It is important to support this variety of 322 operating models to generally facilitate deployment and to allow for 323 some special scenarios. One special scenario has a validation 324 service that is monetized, most likely by the manufacturer. In 325 another, a privacy proxy service processes the EAT before it is 326 transmitted to the relying party. In yet another, symmetric key 327 material is used for signing. In this case the manufacturer should 328 perform the verification, because any release of the key material 329 would enable a participant other than the entity to create valid 330 signed EATs. 332 1.5. What is Not Standardized 334 The following is not standardized for EAT, just the same they are not 335 standardized for CWT or JWT. 337 1.5.1. Transmission Protocol 339 EATs may be transmitted by any protocol the same as CWTs and JWTs. 340 For example, they might be added in extension fields of other 341 protocols, bundled into an HTTP header, or just transmitted as files. 342 This flexibility is intentional to allow broader adoption. This 343 flexibility is possible because EAT's are self-secured with signing 344 (and possibly additionally with encryption and anti-replay). The 345 transmission protocol is not required to fulfill any additional 346 security requirements. 348 For certain devices, a direct connection may not exist between the 349 EAT-producing device and the Relying Party. In such cases, the EAT 350 should be protected against malicious access. The use of COSE and 351 JOSE allows for signing and encryption of the EAT. Therefore, even 352 if the EAT is conveyed through intermediaries between the device and 353 Relying Party, such intermediaries cannot easily modify the EAT 354 payload or alter the signature. 356 1.5.2. Signing Scheme 358 The term "signing scheme" is used to refer to the system that 359 includes end-end process of establishing signing attestation key 360 material in the entity, signing the EAT, and verifying it. This 361 might involve key IDs and X.509 certificate chains or something 362 similar but different. The term "signing algorithm" refers just to 363 the algorithm ID in the COSE signing structure. No particular 364 signing algorithm or signing scheme is required by this standard. 366 There are three main implementation issues driving this. First, 367 secure non-volatile storage space in the entity for the attestation 368 key material may be highly limited, perhaps to only a few hundred 369 bits, on some small IoT chips. Second, the factory cost of 370 provisioning key material in each chip or device may be high, with 371 even millisecond delays adding to the cost of a chip. Third, 372 privacy-preserving signing schemes like ECDAA (Elliptic Curve Direct 373 Anonymous Attestation) are complex and not suitable for all use 374 cases. 376 Over time to faciliate interoperability, some signing schemes may be 377 defined in EAT profiles or other documents either in the IETF or 378 outside. 380 2. Terminology 382 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 383 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 384 "OPTIONAL" in this document are to be interpreted as described in BCP 385 14 [RFC2119] [RFC8174] when, and only when, they appear in all 386 capitals, as shown here. 388 This document reuses terminology from JWT [RFC7519], COSE [RFC8152], 389 and CWT [RFC8392]. 391 Claim Name. The human-readable name used to identify a claim. 393 Claim Key. The CBOR map key or JSON name used to identify a claim. 395 Claim Value. The value portion of the claim. A claim value can be 396 any CBOR data item or JSON value. 398 CWT Claims Set. The CBOR map or JSON object that contains the claims 399 conveyed by the CWT or JWT. 401 Attestation Key Material (AKM). The key material used to sign the 402 EAT token. If it is done symmetrically with HMAC, then this is a 403 simple symmetric key. If it is done with ECC, such as an IEEE 404 DevID [IDevID], then this is the private part of the EC key pair. 405 If ECDAA is used, (e.g., as used by Enhanced Privacy ID, i.e. 406 EPID) then it is the key material needed for ECDAA. 408 3. The Claims 410 This section describes new claims defined for attestation. It also 411 mentions several claims defined by CWT and JWT that are particularly 412 important for EAT. 414 Note also: * Any claim defined for CWT or JWT may be used in an EAT 415 including those in the CWT [IANA.CWT.Claims] and JWT IANA 416 [IANA.JWT.Claims] claims registries. 418 o All claims are optional 420 o No claims are mandatory 422 o All claims that are not understood by implementations MUST be 423 ignored 425 There are no default values or meanings assigned to absent claims 426 other than they are not reported. The reason for a claim's absence 427 may be the implementation not supporting the claim, an inability to 428 determine its value, or a preference to report in a different way 429 such as a proprietary claim. 431 CDDL along with text descriptions is used to define each claim 432 indepdent of encoding. Each claim is defined as a CDDL group (the 433 group is a general aggregation and type definition feature of CDDL). 434 In the encoding section Section 6, the CDDL groups turn into CBOR map 435 entries and JSON name/value pairs. 437 TODO: add paragraph here about use for Attestation Evidence and for 438 Results. 440 3.1. Token ID Claim (cti and jti) 442 CWT defines the "cti" claim. JWT defines the "jti" claim. These are 443 equivalent to each other in EAT and carry a unique token identifier 444 as they do in JWT and CWT. They may be used to defend against re use 445 of the token but are distinct from the nonce that is used by the 446 relying party to guarantee freshness and defend against replay. 448 3.2. Timestamp claim (iat) 450 The "iat" claim defined in CWT and JWT is used to indicate the date- 451 of-creation of the token, the time at which the claims are collected 452 and the token is composed and signed. 454 The data for some claims may be held or cached for some period of 455 time before the token is created. This period may be long, even 456 days. Examples are measurements taken at boot or a geographic 457 position fix taken the last time a satellite signal was received. 458 There are individual timestamps associated with these claims to 459 indicate their age is older than the "iat" timestamp. 461 CWT allows the use floating-point for this claim. EAT disallows the 462 use of floating-point. No token may contain an iat claim in float- 463 point format. Any recipient of a token with a floating-point format 464 iat claim may consider it an error. A 64-bit integer representation 465 of epoch time can represent a range of +/- 500 billion years, so the 466 only point of a floating-point timestamp is to have precession 467 greater than one second. This is not needed for EAT. 469 3.3. Nonce Claim (nonce) 471 All EATs should have a nonce to prevent replay attacks. The nonce is 472 generated by the relying party, the end consumer of the token. It is 473 conveyed to the entity over whatever transport is in use before the 474 token is generated and then included in the token as the nonce claim. 476 This documents the nonce claim for registration in the IANA CWT 477 claims registry. This is equivalent to the JWT nonce claim that is 478 already registered. 480 The nonce must be at least 8 bytes (64 bits) as fewer are unlikely to 481 be secure. A maximum of 64 bytes is set to limit the memory a 482 constrained implementation uses. This size range is not set for the 483 already-registered JWT nonce, but it should follow this size 484 recommendation when used in an EAT. 486 Multiple nonces are allowed to accommodate multistage verification 487 and consumption. 489 3.3.1. nonce CDDL 491 nonce-type = bstr .size (8..64) 493 nonce-claim = ( 494 nonce => nonce-type / [ 2* nonce-type ] 495 ) 497 3.4. Universal Entity ID Claim (ueid) 499 UEID's identify individual manufactured entities / devices such as a 500 mobile phone, a water meter, a Bluetooth speaker or a networked 501 security camera. It may identify the entire device or a submodule or 502 subsystem. It does not identify types, models or classes of devices. 503 It is akin to a serial number, though it does not have to be 504 sequential. 506 UEID's must be universally and globally unique across manufacturers 507 and countries. UEIDs must also be unique across protocols and 508 systems, as tokens are intended to be embedded in many different 509 protocols and systems. No two products anywhere, even in completely 510 different industries made by two different manufacturers in two 511 different countries should have the same UEID (if they are not global 512 and universal in this way, then relying parties receiving them will 513 have to track other characteristics of the device to keep devices 514 distinct between manufacturers). 516 There are privacy considerations for UEID's. See Section 8.1. 518 The UEID should be permanent. It should never change for a given 519 device / entity. In addition, it should not be reprogrammable. 520 UEID's are variable length. All implementations MUST be able to 521 receive UEID's that are 33 bytes long (1 type byte and 256 bits). 522 The recommended maximum sent is also 33 bytes. 524 When the entity constructs the UEID, the first byte is a type and the 525 following bytes the ID for that type. Several types are allowed to 526 accommodate different industries and different manufacturing 527 processes and to give options to avoid paying fees for certain types 528 of manufacturer registrations. 530 Creation of new types requires a Standards Action [RFC8126]. 532 +------+------+-----------------------------------------------------+ 533 | Type | Type | Specification | 534 | Byte | Name | | 535 +------+------+-----------------------------------------------------+ 536 | 0x01 | RAND | This is a 128, 192 or 256 bit random number | 537 | | | generated once and stored in the device. This may | 538 | | | be constructed by concatenating enough identifiers | 539 | | | to make up an equivalent number of random bits and | 540 | | | then feeding the concatenation through a | 541 | | | cryptographic hash function. It may also be a | 542 | | | cryptographic quality random number generated once | 543 | | | at the beginning of the life of the device and | 544 | | | stored. It may not be smaller than 128 bits. | 545 | 0x02 | IEEE | This makes use of the IEEE company identification | 546 | | EUI | registry. An EUI is either an EUI-48, EUI-60 or | 547 | | | EUI-64 and made up of an OUI, OUI-36 or a CID, | 548 | | | different registered company identifiers, and some | 549 | | | unique per-device identifier. EUIs are often the | 550 | | | same as or similar to MAC addresses. This type | 551 | | | includes MAC-48, an obsolete name for EUI-48. (Note | 552 | | | that while devices with multiple network interfaces | 553 | | | may have multiple MAC addresses, there is only one | 554 | | | UEID for a device) [IEEE.802-2001], [OUI.Guide] | 555 | 0x03 | IMEI | This is a 14-digit identifier consisting of an | 556 | | | 8-digit Type Allocation Code and a 6-digit serial | 557 | | | number allocated by the manufacturer, which SHALL | 558 | | | be encoded as byte string of length 14 with each | 559 | | | byte as the digit's value (not the ASCII encoding | 560 | | | of the digit; the digit 3 encodes as 0x03, not | 561 | | | 0x33). The IMEI value encoded SHALL NOT include | 562 | | | Luhn checksum or SVN information. [ThreeGPP.IMEI] | 563 +------+------+-----------------------------------------------------+ 565 Table 1: UEID Composition Types 567 UEID's are not designed for direct use by humans (e.g., printing on 568 the case of a device), so no textual representation is defined. 570 The consumer (the relying party) of a UEID MUST treat a UEID as a 571 completely opaque string of bytes and not make any use of its 572 internal structure. For example, they should not use the OUI part of 573 a type 0x02 UEID to identify the manufacturer of the device. Instead 574 they should use the oemid claim that is defined elsewhere. The 575 reasons for this are: 577 o UEIDs types may vary freely from one manufacturer to the next. 579 o New types of UEIDs may be created. For example, a type 0x07 UEID 580 may be created based on some other manufacturer registration 581 scheme. 583 o Device manufacturers are allowed to change from one type of UEID 584 to another anytime they want. For example, they may find they can 585 optimize their manufacturing by switching from type 0x01 to type 586 0x02 or vice versa. The main requirement on the manufacturer is 587 that UEIDs be universally unique. 589 3.4.1. ueid CDDL 591 ueid-type = bstr .size (7..33) 593 ueid-claim = ( 594 ueid => ueid-type 595 ) 597 3.5. Origination Claim (origination) 599 TODO: this claim is likely to be dropped in favor of Endorsement 600 identifier and locators. 602 This claim describes the parts of the device or entity that are 603 creating the EAT. Often it will be tied back to the device or chip 604 manufacturer. The following table gives some examples: 606 +-------------------+-----------------------------------------------+ 607 | Name | Description | 608 +-------------------+-----------------------------------------------+ 609 | Acme-TEE | The EATs are generated in the TEE authored | 610 | | and configured by "Acme" | 611 | Acme-TPM | The EATs are generated in a TPM manufactured | 612 | | by "Acme" | 613 | Acme-Linux-Kernel | The EATs are generated in a Linux kernel | 614 | | configured and shipped by "Acme" | 615 | Acme-TA | The EATs are generated in a Trusted | 616 | | Application (TA) authored by "Acme" | 617 +-------------------+-----------------------------------------------+ 618 TODO: consider a more structure approach where the name and the URI 619 and other are in separate fields. 621 TODO: This needs refinement. It is somewhat parallel to issuer claim 622 in CWT in that it describes the authority that created the token. 624 3.5.1. origination CDDL 626 origination-claim = ( 627 origination => string-or-uri 628 ) 630 3.6. OEM Identification by IEEE (oemid) 632 The IEEE operates a global registry for MAC addresses and company 633 IDs. This claim uses that database to identify OEMs. The contents 634 of the claim may be either an IEEE MA-L, MA-M, MA-S or an IEEE CID 635 [IEEE.RA]. An MA-L, formerly known as an OUI, is a 24-bit value used 636 as the first half of a MAC address. MA-M similarly is a 28-bit value 637 uses as the first part of a MAC address, and MA-S, formerly known as 638 OUI-36, a 36-bit value. Many companies already have purchased one of 639 these. A CID is also a 24-bit value from the same space as an MA-L, 640 but not for use as a MAC address. IEEE has published Guidelines for 641 Use of EUI, OUI, and CID [OUI.Guide] and provides a lookup services 642 [OUI.Lookup] 644 Companies that have more than one of these IDs or MAC address blocks 645 should pick one and prefer that for all their devices. 647 Commonly, these are expressed in Hexadecimal Representation 648 [IEEE.802-2001] also called the Canonical format. When this claim is 649 encoded the order of bytes in the bstr are the same as the order in 650 the Hexadecimal Representation. For example, an MA-L like "AC-DE-48" 651 would be encoded in 3 bytes with values 0xAC, 0xDE, 0x48. For JSON 652 encoded tokens, this is further base64url encoded. 654 3.6.1. oemid CDDL 656 oemid-claim = ( 657 oemid => bstr 658 ) 660 3.7. Hardware Version Claims (hardware-version-claims) 662 The hardware version can be claimed at three different levels, the 663 chip, the circuit board and the final device assembly. An EAT can 664 include any combination these claims. 666 The hardware version is a simple text string the format of which is 667 set by each manufacturer. The structure and sorting order of this 668 text string can be specified using the version-scheme item from 669 CoSWID [CoSWID]. 671 The hardware version can also be given by a 13-digit European Article 672 Number [EAN-13]. An EAN-13 is also known as an International Article 673 Number or most commonly as a bar code. This claim is the ASCII text 674 representation of actual digits often printed with a bar code. Use 675 of this claim must comply with the EAN allocation and assignment 676 rules. For example, this requires the manufacturer to obtain a 677 manufacture code from GS1. 679 Both the simple version string and EAN-13 versions may be included 680 for the same hardware. 682 chip-version-claim = ( 683 chip-version => tstr 684 ) 686 chip-version-scheme-claim = ( 687 chip-version-scheme => $version-scheme 688 ) 690 board-version-claim = ( 691 board-version => tstr 692 ) 694 board-version-scheme-claim = ( 695 board-version-scheme => $version-scheme 696 ) 698 device-version-claim = ( 699 device-version => tstr 700 ) 702 device-version-scheme-claim = ( 703 device-version-scheme => $version-scheme 704 ) 706 ean-type = text .regexp "[0-9]{13}" 708 ean-chip-version-claim = ( 709 ean-chip-version => ean-type 710 ) 712 ean-board-version-claim = ( 713 ean-board-version => ean-type 714 ) 716 ean-device-version-claim = ( 717 ean-device-version => ean-type 718 ) 720 hardware-version-claims = ( 721 ? chip-version-claim, 722 ? board-version-claim, 723 ? device-version-claim, 724 ? chip-version-scheme-claim, 725 ? board-version-scheme-claim, 726 ? device-version-scheme-claim, 727 ? ean-chip-version-claim, 728 ? ean-board-version-claim, 729 ? ean-device-version-claim, 730 ) 732 3.8. Software Description and Version 734 TODO: Add claims that reference CoSWID. 736 3.9. The Security Level Claim (security-level) 738 This claim characterizes the device/entity ability to defend against 739 attacks aimed at capturing the signing key, forging claims and at 740 forging EATs. This is done by defining four security levels as 741 described below. This is similar to the key protection types defined 742 by the Fast Identity Online (FIDO) Alliance [FIDO.Registry]. 744 These claims describe security environment and countermeasures 745 available on the end-entity / client device where the attestation key 746 reside and the claims originate. 748 1 - Unrestricted There is some expectation that implementor will 749 protect the attestation signing keys at this level. Otherwise the 750 EAT provides no meaningful security assurances. 752 2- Restricted Entities at this level should not be general-purpose 753 operating environments that host features such as app download 754 systems, web browsers and complex productivity applications. It 755 is akin to the Secure Restricted level (see below) without the 756 security orientation. Examples include a Wi-Fi subsystem, an IoT 757 camera, or sensor device. 759 3 - Secure Restricted Entities at this level must meet the criteria 760 defined by FIDO Allowed Restricted Operating Environments 761 [FIDO.AROE]. Examples include TEE's and schemes using 762 virtualization-based security. Like the FIDO security goal, 763 security at this level is aimed at defending well against large- 764 scale network / remote attacks against the device. 766 4 - Hardware Entities at this level must include substantial defense 767 against physical or electrical attacks against the device itself. 768 It is assumed any potential attacker has captured the device and 769 can disassemble it. Example include TPMs and Secure Elements. 771 The entity should claim the highest security level it achieves and no 772 higher. This set is not extensible so as to provide a common 773 interoperable description of security level to the relying party. If 774 a particular implementation considers this claim to be inadequate, it 775 can define its own proprietary claim. It may consider including both 776 this claim as a coarse indication of security and its own proprietary 777 claim as a refined indication. 779 This claim is not intended as a replacement for a proper end-device 780 security certification schemes such as those based on FIPS 140 781 [FIPS-140] or those based on Common Criteria [Common.Criteria]. The 782 claim made here is solely a self-claim made by the Entity Originator. 784 3.9.1. security-level CDDL 786 security-level-type = &( 787 unrestricted: 1, 788 restricted: 2, 789 secure-restricted: 3, 790 hardware: 4 791 ) 793 security-level-claim = ( 794 security-level => security-level-type 795 ) 797 3.10. Secure Boot Claim (secure-boot) 799 The value of true indicates secure boot is enabled. Secure boot is 800 considered enabled when base software, the firmware and operating 801 system, are under control of the entity manufacturer identified in 802 the oemid claimd described in Section 3.6. This may because the 803 software is in ROM or because it is cryptographically authenticated 804 or some combination of the two or other. 806 3.10.1. secure-boot CDDL 808 secure-boot-claim = ( 809 secure-boot => bool 810 ) 812 3.11. Debug Status Claim (debug-status) 814 This applies to system-wide or submodule-wide debug facilities of the 815 target device / submodule like JTAG and diagnostic hardware built 816 into chips. It applies to any software debug facilities related to 817 root, operating system or privileged software that allow system-wide 818 memory inspection, tracing or modification of non-system software 819 like user mode applications. 821 This characterization assumes that debug facilities can be enabled 822 and disabled in a dynamic way or be disabled in some permanent way 823 such that no enabling is possible. An example of dynamic enabling is 824 one where some authentication is required to enable debugging. An 825 example of permanent disabling is blowing a hardware fuse in a chip. 826 The specific type of the mechanism is not taken into account. For 827 example, it does not matter if authentication is by a global password 828 or by per-device public keys. 830 As with all claims, the absence of the debug level claim means it is 831 not reported. A conservative interpretation might assume the Not 832 Disabled state. It could however be that it is reported in a 833 proprietary claim. 835 This claim is not extensible so as to provide a common interoperable 836 description of debug status to the relying party. If a particular 837 implementation considers this claim to be inadequate, it can define 838 its own proprietary claim. It may consider including both this claim 839 as a coarse indication of debug status and its own proprietary claim 840 as a refined indication. 842 The higher levels of debug disabling requires that all debug 843 disabling of the levels below it be in effect. Since the lowest 844 level requires that all of the target's debug be currently disabled, 845 all other levels require that too. 847 There is no inheritance of claims from a submodule to a superior 848 module or vice versa. There is no assumption, requirement or 849 guarantee that the target of a superior module encompasses the 850 targets of submodules. Thus, every submodule must explicitly 851 describe its own debug state. The verifier or relying party 852 receiving an EAT cannot assume that debug is turned off in a 853 submodule because there is a claim indicating it is turned off in a 854 superior module. 856 An individual target device / submodule may have multiple debug 857 facilities. The use of plural in the description of the states 858 refers to that, not to any aggregation or inheritance. 860 The architecture of some chips or devices may be such that a debug 861 facility operates for the whole chip or device. If the EAT for such 862 a chip includes submodules, then each submodule should independently 863 report the status of the whole-chip or whole-device debug facility. 864 This is the only way the relying party can know the debug status of 865 the submodules since there is no inheritance. 867 3.11.1. Enabled 869 If any debug facility, even manufacturer hardware diagnostics, is 870 currently enabled, then this level must be indicated. 872 3.11.2. Disabled 874 This level indicates all debug facilities are currently disabled. It 875 may be possible to enable them in the future, and it may also be 876 possible that they were enabled in the past after the target device/ 877 sub-system booted/started, but they are currently disabled. 879 3.11.3. Disabled Since Boot 881 This level indicates all debug facilities are currently disabled and 882 have been so since the target device/sub-system booted/started. 884 3.11.4. Disabled Permanently 886 This level indicates all non-manufacturer facilities are permanently 887 disabled such that no end user or developer cannot enable them. Only 888 the manufacturer indicated in the OEMID claim can enable them. This 889 also indicates that all debug facilities are currently disabled and 890 have been so since boot/start. 892 3.11.5. Disabled Fully and Permanently 894 This level indicates that all debug capabilities for the target 895 device/sub-module are permanently disabled. 897 3.11.6. debug-status CDDL 899 debug-status-type = &( 900 enabled: 0, 901 disabled: 1, 902 disabled-since-boot: 2, 903 disabled-permanently: 3, 904 disabled-fully-and-permanently: 4 905 ) 907 debug-status-claim = ( 908 debug-status => debug-status-type 909 ) 911 3.12. Including Keys 913 An EAT may include a cryptographic key such as a public key. The 914 signing of the EAT binds the key to all the other claims in the 915 token. 917 The purpose for inclusion of the key may vary by use case. For 918 example, the key may be included as part of an IoT device onboarding 919 protocol. When the FIDO protocol includes a pubic key in its 920 attestation message, the key represents the binding of a user, device 921 and relying party. This document describes how claims containing 922 keys should be defined for the various use cases. It does not define 923 specific claims for specific use cases. 925 Keys in CBOR format tokens SHOULD be the COSE_Key format [RFC8152] 926 and keys in JSON format tokens SHOULD be the JSON Web Key format 927 [RFC7517]. These two formats support many common key types. Their 928 use avoids the need to decode other serialization formats. These two 929 formats can be extended to support further key types through their 930 IANA registries. 932 The general confirmation claim format [RFC8747], [RFC7800] may also 933 be used. It provides key encryption. It also allows for inclusion 934 by reference through a key ID. The confirmation claim format may 935 employed in the definition of some new claim for a a particular use 936 case. 938 When the actual confirmation claim is included in an EAT, this 939 document associates no use case semantics other than proof of 940 posession. Different EAT use cases may choose to associate further 941 semantics. The key in the confirmation claim MUST be protected the 942 same as the key used to sign the EAT. That is, the same, equivalent 943 or better hardware defenses, access controls, key generation and such 944 must be used. 946 3.13. The Location Claim (location) 948 The location claim gives the location of the device entity from which 949 the attestation originates. It is derived from the W3C Geolocation 950 API [W3C.GeoLoc]. The latitude, longitude, altitude and accuracy 951 must conform to [WGS84]. The altitude is in meters above the [WGS84] 952 ellipsoid. The two accuracy values are positive numbers in meters. 953 The heading is in degrees relative to true north. If the device is 954 stationary, the heading is NaN (floating-point not-a-number). The 955 speed is the horizontal component of the device velocity in meters 956 per second. 958 When encoding floating-point numbers half-precision should not be 959 used. It usually does not provide enough precision for a geographic 960 location. It is not a requirement that the receiver of an EAT 961 implement half-precision, so the receiver may not be able to decode 962 the location. 964 The location may have been cached for a period of time before token 965 creation. For example, it might have been minutes or hours or more 966 since the last contact with a GPS satellite. Either the timestamp or 967 age data item can be used to quantify the cached period. The 968 timestamp data item is preferred as it a non-relative time. 970 The age data item can be used when the entity doesn't know what time 971 it is either because it doesn't have a clock or it isn't set. The 972 entity must still have a "ticker" that can measure a time interval. 973 The age is the interval between acquisition of the location data and 974 token creation. 976 See location-related privacy considerations in Section 8.2 below. 978 3.13.1. location CDDL 979 location-type = { 980 latitude => number, 981 longitude => number, 982 ? altitude => number, 983 ? accuracy => number, 984 ? altitude-accuracy => number, 985 ? heading => number, 986 ? speed => number, 987 ? timestamp => ~time-int, 988 ? age => uint 989 } 991 latitude = 1 992 longitude = 2 993 altitude = 3 994 accuracy = 4 995 altitude-accuracy = 5 996 heading = 6 997 speed = 7 998 timestamp = 8 999 age = 9 1001 location-claim = ( 1002 location => location-type 1003 ) 1005 3.14. The Uptime Claim (uptime) 1007 The "uptime" claim contains a value that represents the number of 1008 seconds that have elapsed since the entity or submod was last booted. 1010 3.14.1. uptime CDDL 1012 uptime-claim = ( 1013 uptime => uint 1014 ) 1016 3.14.2. The Boot Seed Claim (boot-seed) 1018 The Boot Seed claim is a random value created at system boot time 1019 that will allow differentiation of reports from different boot 1020 sessions. This value is usually public and not protected. It is not 1021 the same as a seed for a random number generator which must be kept 1022 secret. 1024 boot-seed-claim = ( 1025 boot-seed => bytes 1026 ) 1028 3.15. The Intended Use Claim (intended-use) 1030 EAT's may be used in the context of several different applications. 1031 The intended-use claim provides an indication to an EAT consumer 1032 about the intended usage of the token. This claim can be used as a 1033 way for an application using EAT to internally distinguish between 1034 different ways it uses EAT. 1036 1 - Generic Generic attestation describes an application where the 1037 EAT consumer requres the most up-to-date security assessment of 1038 the attesting entity. It is expected that this is the most 1039 commonly-used application of EAT. 1041 2- Registration Entities that are registering for a new service may 1042 be expected to provide an attestation as part of the registration 1043 process. This intended-use setting indicates that the attestation 1044 is not intended for any use but registration. 1046 3 - Provisioning Entities may be provisioned with different values 1047 or settings by an EAT consumer. Examples include key material or 1048 device management trees. The consumer may require an EAT to 1049 assess device security state of the entity prior to provisioning. 1051 4 - Certificate Issuance (Certificate Signing Request) Certifying 1052 authorities (CA's) may require attestations prior to the issuance 1053 of certificates related to keypairs hosted at the entity. An EAT 1054 may be used as part of the certificate signing request (CSR). 1056 5 - Proof-of-Possession An EAT consumer may require an attestation 1057 as part of an accompanying proof-of-possession (PoP) appication. 1058 More precisely, a PoP transaction is intended to provide to the 1059 recipient cryptographically-verifiable proof that the sender has 1060 posession of a key. This kind of attestation may be neceesary to 1061 verify the security state of the entity storing the private key 1062 used in a PoP application. 1064 3.15.1. intended-use CDDL 1065 intended-use-type = &( 1066 generic: 1, 1067 registration: 2, 1068 provisioning: 3, 1069 csr: 4, 1070 pop: 5 1071 ) 1073 intended-use-claim = ( 1074 intended-use => intended-use-type 1075 ) 1077 3.16. The Profile Claim (profile) 1079 The profile claim is a text string that simply gives the name of the 1080 profile to which the token purports to adhere to. It may name an 1081 IETF document, some other document or no particular document. There 1082 is no requirement that the named document be publicly accessible. 1084 See Section 5 for a detailed description of a profile. 1086 Note that this named "eat-profile" for JWT and is distinct from the 1087 already registered "profile" claim in the JWT claims registry. 1089 profile-claim = ( 1090 profile => tstr 1091 ) 1093 3.17. The Submodules Part of a Token (submods) 1095 Some devices are complex, having many subsystems or submodules. A 1096 mobile phone is a good example. It may have several connectivity 1097 submodules for communications (e.g., Wi-Fi and cellular). It may 1098 have subsystems for low-power audio and video playback. It may have 1099 one or more security-oriented subsystems like a TEE or a Secure 1100 Element. 1102 The claims for each these can be grouped together in a submodule. 1104 The submods part of a token are in a single map/object with many 1105 entries, one per submodule. There is only one submods map in a 1106 token. It is identified by its specific label. It is a peer to 1107 other claims, but it is not called a claim because it is a container 1108 for a claim set rather than an individual claim. This submods part 1109 of a token allows what might be called recursion. It allows claim 1110 sets inside of claim sets inside of claims sets... 1112 3.17.1. Two Types of Submodules 1114 Each entry in the submod map is one of two types: 1116 o A non-token submodule that is a map or object directly containing 1117 claims for the submodule. 1119 o A nested EAT that is a fully formed, independently signed EAT 1120 token 1122 3.17.1.1. Non-token Submodules 1124 This is simply a map or object containing claims about the submodule. 1126 It may contain claims that are the same as its surrounding token or 1127 superior submodules. For example, the top-level of the token may 1128 have a UEID, a submod may have a different UEID and a further 1129 subordinate submodule may also have a UEID. 1131 It is signed/encrypted along with the rest of the token and thus the 1132 claims are secured by the same Attester with the same signing key as 1133 the rest of the token. 1135 If a token is in CBOR format (a CWT or a UCCS), all non-token 1136 submodules must be CBOR format. If a token in in JSON format (a 1137 JWT), all non-token submodules must be in JSON format. 1139 When decoding, this type of submodule is recognized from the other 1140 type by being a data item of type map for CBOR or type object for 1141 JSON. 1143 3.17.1.2. Nested EATs 1145 This type of submodule is a fully formed secured EAT as defined in 1146 this document except that it MUST NOT be a UCCS or an unsecured JWT. 1147 A nested token that is one that is always secured using COSE or JOSE, 1148 usually by an independent Attester. When the surrounding EAT is a 1149 CWT or secured JWT, the nested token becomes securely bound with the 1150 other claims in the surrounding token. 1152 It is allowed to have a CWT as a submodule in a JWT and vice versa, 1153 but this SHOULD be avoided unless necessary. 1155 3.17.1.2.1. Surrounding EAT is CBOR format 1157 They type of an EAT nested in a CWT is determined by whether the CBOR 1158 type is a text string or a byte string. If a text string, then it is 1159 a JWT. If a byte string, then it is a CWT. 1161 A CWT nested in a CBOR-format token is always wrapped by a byte 1162 string for easier handling with standard CBOR decoders and token 1163 processing APIs that will typically take a byte buffer as input. 1165 Nested CWTs may be either a CWT CBOR tag or a CWT Protocol Message. 1166 COSE layers in nested CWT EATs MUST be a COSE_Tagged_Message, never a 1167 COSE_Untagged_Message. If a nested EAT has more than one level of 1168 COSE, for example one that is both encrypted and signed, a 1169 COSE_Tagged_message must be used at every level. 1171 3.17.1.2.2. Surrounding EAT is JSON format 1173 When a CWT is nested in a JWT, it must be as a 55799 tag in order to 1174 distinguish it from a nested JWT. 1176 When a nested EAT in a JWT is decoded, first remove the base64url 1177 encoding. Next, check to see if it starts with the bytes 0xd9d9f7. 1178 If so, then it is a CWT as a JWT will never start with these four 1179 bytes. If not if it is a JWT. 1181 Other than the 55799 tag requirement, tag usage for CWT's nested in a 1182 JSON format token follow the same rules as for CWTs nested in CBOR- 1183 format tokens. It may be a CWT CBOR tag or a CWT Protocol Message 1184 and COSE_Tagged_Message MUST be used at all COSE layers. 1186 3.17.1.3. Unsecured JWTs and UCCS Tokens as Submodules 1188 To incorporate a UCCS token as a submodule, it MUST be as a non-token 1189 submodule. This can be accomplished inserting the content of the 1190 UCCS Tag into the submodule map. The content of a UCCS tag is 1191 exactly a map of claims as required for a non-token submodule. If 1192 the UCCS is not a UCCS tag, then it can just be inserted into the 1193 submodule map directly. 1195 The definition of a nested EAT type of submodule is that it is one 1196 that is secured (signed) by an Attester. Since UCCS tokens are 1197 unsecured, they do not fulfill this definition and must be non-token 1198 submodules. 1200 To incorporate an Unsecured JWT as a submodule, the null-security 1201 JOSE wrapping should be removed. The resulting claims set should be 1202 inserted as a non-token submodule. 1204 To incorporate a UCCS token in a surrounding JSON token, the UCCS 1205 token claims should be translated from CBOR to JSON. To incorporate 1206 an Unsecured JWT into a surrounding CBOR-format token, the null- 1207 security JOSE should be removed and the claims translated from JSON 1208 to CBOR. 1210 3.17.2. No Inheritance 1212 The subordinate modules do not inherit anything from the containing 1213 token. The subordinate modules must explicitly include all of their 1214 claims. This is the case even for claims like the nonce and age. 1216 This rule is in place for simplicity. It avoids complex inheritance 1217 rules that might vary from one type of claim to another. 1219 3.17.3. Security Levels 1221 The security level of the non-token subordinate modules should always 1222 be less than or equal to that of the containing modules in the case 1223 of non-token submodules. It makes no sense for a module of lesser 1224 security to be signing claims of a module of higher security. An 1225 example of this is a TEE signing claims made by the non-TEE parts 1226 (e.g. the high-level OS) of the device. 1228 The opposite may be true for the nested tokens. They usually have 1229 their own more secure key material. An example of this is an 1230 embedded secure element. 1232 3.17.4. Submodule Names 1234 The label or name for each submodule in the submods map is a text 1235 string naming the submodule. No submodules may have the same name. 1237 3.17.5. submods CDDL 1238 ; The part of a token that contains all the submodules. It is a peer 1239 ; with the claims in the token, but not a claim, only a map/object to 1240 ; hold all the submodules. 1242 submods-part = ( 1243 submods => submods-type 1244 ) 1246 submods-type = { + submod-type } 1248 ; The type of a submodule which can either be a nested claim set or a 1249 ; nested separately signed token. Nested tokens are wrapped in a bstr 1250 ; or a tstr. 1252 submod-type = ( 1253 submod-name => eat-claim-set / nested-token 1254 ) 1256 ; When this is a bstr, the contents are an eat-token in CWT or UCCS 1257 ; format. When this is a tstr, the contents are an eat-token in JWT 1258 ; format. 1260 nested-token = bstr / tstr; 1262 ; Each submodule has a unique text string name. 1264 submod-name = tstr 1266 4. Endorsements and Verification Keys 1268 TODO: fill this section in. It will discuss key IDs, endorsement ID 1269 and such that are needed as input needed to by the Verifier to verify 1270 the signature. This will NOT discuss the contents of an Endorsement, 1271 just and ID/locator. 1273 5. Profiles 1275 This EAT specification does not gaurantee that implementations of it 1276 will interoperate. The variability in this specification is 1277 necessary to accommodate the widely varying use cases. An EAT 1278 profile narrows the specification for a specific use case. An ideal 1279 EAT profile will gauarantee interoperability. 1281 The profile can be named in the token using the profile claim 1282 described in Section 3.16. 1284 5.1. List of Profile Issues 1286 The following is a list of EAT, CWT, UCCS, JWS, COSE, JOSE and CBOR 1287 options that a profile should address. 1289 5.1.1. Use of JSON, CBOR or both 1291 The profile should indicate whether the token format should be CBOR, 1292 JSON, both or even some other encoding. If some other encoding, a 1293 specification for how the CDDL described here is serialized in that 1294 encoding is necessary. 1296 This should be addressed for the top-level token and for any nested 1297 tokens. For example, a profile might require all nested tokens to be 1298 of the same encoding of the top level token. 1300 5.1.2. CBOR Map and Array Encoding 1302 The profile should indicate whether definite-length arrays/maps, 1303 indefinite-length arrays/maps or both are allowed. A good default is 1304 to allow only definite-length arrays/maps. 1306 An alternate is to allow both definite and indefinite-length arrays/ 1307 maps. The decoder should accept either. Encoders that need to fit 1308 on very small hardware or be actually implement in hardware can use 1309 indefinite-length encoding. 1311 This applies to individual EAT claims, CWT and COSE parts of the 1312 implementation. 1314 5.1.3. CBOR String Encoding 1316 The profile should indicate whether definite-length strings, 1317 indefinite-length strings or both are allowed. A good default is to 1318 allow only definite-length strings. As with map and array encoding, 1319 allowing indefinite-length strings can be beneficial for some smaller 1320 implementations. 1322 5.1.4. COSE/JOSE Protection 1324 COSE and JOSE have several options for signed, MACed and encrypted 1325 messages. EAT/CWT has the option to have no protection using UCCS 1326 and JOSE has a NULL protection option. It is possible to implement 1327 no protection, sign only, MAC only, sign then encrypt and so on. All 1328 combinations allowed by COSE, JOSE, JWT, CWT and UCCS are allowed by 1329 EAT. 1331 The profile should list the protections that must be supported by all 1332 decoders implementing the profile. The encoders them must implement 1333 a subset of what is listed for the decoders, perhaps only one. 1335 Implementations may choose to sign or MAC before encryption so that 1336 the implementation layer doing the signing or MACing can be the 1337 smallest. It is often easier to make smaller implementations more 1338 secure, perhaps even implementing in solely in hardware. The key 1339 material for a signature or MAC is a private key, while for 1340 encryption it is likely to be a public key. The key for encryption 1341 requires less protection. 1343 5.1.5. COSE/JOSE Algorithms 1345 The profile document should list the COSE algorithms that a Verifier 1346 must implement. The Attester will select one of them. Since there 1347 is no negotiation, the Verifier should implement all algorithms 1348 listed in the profile. 1350 5.1.6. Verification Key Identification 1352 Section Section 4 describes a number of methods for identifying a 1353 verification key. The profile document should specify one of these 1354 or one that is not described. The ones described in this document 1355 are only roughly described. The profile document should go into the 1356 full detail. 1358 5.1.7. Endorsement Identification 1360 Similar to, or perhaps the same as Verification Key Identification, 1361 the profile may wish to specify how Endorsements are to be 1362 identified. However note that Endorsement Identification is 1363 optional, where as key identification is not. 1365 5.1.8. Required Claims 1367 The profile can list claims whose absence results in Verification 1368 failure. 1370 5.1.9. Prohibited Claims 1372 The profile can list claims whose presence results in Verification 1373 failure. 1375 5.1.10. Additional Claims 1377 The profile may describe entirely new claims. These claims can be 1378 required or optional. 1380 5.1.11. Refined Claim Definition 1382 The profile may lock down optional aspects of individual claims. For 1383 example, it may require altitude in the location claim, or it may 1384 require that HW Versions always be described using EAN-13. 1386 5.1.12. CBOR Tags 1388 The profile should specify whether the token should be a CWT Tag or 1389 not. Similarly, the profile should specify whether the token should 1390 be a UCCS tag or not. 1392 When COSE protection is used, the profile should specify whether COSE 1393 tags are used or not. Note that RFC 8392 requires COSE tags be used 1394 in a CWT tag. 1396 Often a tag is unncessary because the surrounding or carrying 1397 protocol identifies the object as an EAT. 1399 6. Encoding 1401 This makes use of the types defined in CDDL Appendix D, Standard 1402 Prelude. 1404 Some of the CDDL included here is for claims that are defined in CWT 1405 [RFC8392] or JWT [RFC7519] or are in the IANA CWT or JWT registries. 1406 CDDL was not in use when these claims where defined. 1408 6.1. Common CDDL Types 1410 time-int is identical to the epoch-based time, but disallows 1411 floating-point representation. 1413 string-or-uri = tstr 1415 time-int = #6.1(int) 1417 6.2. CDDL for CWT-defined Claims 1419 This section provides CDDL for the claims defined in CWT. It is non- 1420 normative as [RFC8392] is the authoritative definition of these 1421 claims. 1423 $$eat-extension //= ( 1424 ? issuer => text, 1425 ? subject => text, 1426 ? audience => text, 1427 ? expiration => time, 1428 ? not-before => time, 1429 ? issued-at => time, 1430 ? cwt-id => bytes, 1431 ) 1433 issuer = 1 1434 subject = 2 1435 audience = 3 1436 expiration = 4 1437 not-before = 5 1438 issued-at = 6 1439 cwt-id = 7 1441 6.3. JSON 1443 6.3.1. JSON Labels 1445 ; The following are Claim Keys (labels) assigned for JSON-encoded tokens. 1447 ueid /= "ueid" 1448 nonce /= "nonce" 1449 origination /= "origination" 1450 oemid /= "oemid" 1451 security-level /= "seclevel" 1452 secure-boot /= "secboot" 1453 debug-status /= "dbgstat" 1454 location /= "location" 1455 uptime /= "uptime" 1456 profile /= "eat-profile" 1457 intended-use /= "intuse" 1458 boot-seed /= "bootseed" 1459 submods /= "submods" 1460 timestamp /= "timestamp" 1462 latitude /= "lat" 1463 longitude /= "long" 1464 altitude /= "alt" 1465 accuracy /= "accry" 1466 altitude-accuracy /= "alt-accry" 1467 heading /= "heading" 1468 speed /= "speed" 1469 6.3.2. JSON Interoperability 1471 JSON should be encoded per RFC 8610 Appendix E. In addition, the 1472 following CDDL types are encoded in JSON as follows: 1474 o bstr - must be base64url encoded 1476 o time - must be encoded as NumericDate as described section 2 of 1477 [RFC7519]. 1479 o string-or-uri - must be encoded as StringOrURI as described 1480 section 2 of [RFC7519]. 1482 6.4. CBOR 1484 6.4.1. CBOR Interoperability 1486 CBOR allows data items to be serialized in more than one form. If 1487 the sender uses a form that the receiver can't decode, there will not 1488 be interoperability. 1490 This specification gives no blanket requirements to narrow CBOR 1491 serialization for all uses of EAT. This allows individual uses to 1492 tailor serialization to the environment. It also may result in EAT 1493 implementations that don't interoperate. 1495 One way to guarantee interoperability is to clearly specify CBOR 1496 serialization in a profile document. See Section 5 for a list of 1497 serialization issues that should be addressed. 1499 EAT will be commonly used where the device generating the attestation 1500 is constrained and the receiver/verifier of the attestation is a 1501 capacious server. Following is a set of serialization requirements 1502 that work well for that use case and are guaranteed to interoperate. 1503 Use of this serialization is recommended where possible, but not 1504 required. An EAT profile may just reference the following section 1505 rather than spell out serialization details. 1507 6.4.1.1. EAT Constrained Device Serialization 1509 o Preferred serialization described in section 4.1 of [RFC8949] is 1510 not required. The EAT decoder must accept all forms of number 1511 serialization. The EAT encoder may use any form it wishes. 1513 o The EAT decoder must accept indefinite length arrays and maps as 1514 described in section 3.2.2 of [RFC8949]. The EAT encoder may use 1515 indefinite length arrays and maps if it wishes. 1517 o The EAT decoder must accept indefinite length strings as described 1518 in section 3.2.3 of [RFC8949]. The EAT encoder may use indefinite 1519 length strings if it wishes. 1521 o Sorting of maps by key is not required. The EAT decoder must not 1522 rely on sorting. 1524 o Deterministic encoding described in Section 4.2 of [RFC8949] is 1525 not required. 1527 o Basic validity described in section 5.3.1 of [RFC8949] must be 1528 followed. The EAT encoder must not send duplicate map keys/labels 1529 or invalid UTF-8 strings. 1531 6.5. Collected CDDL 1533 ; This is the top-level definition of the claims in EAT tokens. To 1534 ; form an actual EAT Token, this claim set is enclosed in a COSE, JOSE 1535 ; or UCCS message. 1537 eat-claim-set = { 1538 ? ueid-claim, 1539 ? nonce-claim, 1540 ? origination-claim, 1541 ? oemid-claim, 1542 ? hardware-version-claims, 1543 ? security-level-claim, 1544 ? secure-boot-claim, 1545 ? debug-status-claim, 1546 ? location-claim, 1547 ? uptime-claim, 1548 ? submods-part, 1549 * $$eat-extension, 1550 } 1552 ; This is the top-level definition of an EAT Token. It is a CWT, JWT 1553 ; or UCSS where the payload is an eat-claim-set. A JWT_Message is what 1554 ; is defined by JWT in RFC 7519. (RFC 7519 doesn't use CDDL so a there 1555 ; is no actual CDDL definition of JWT_Message). 1557 eat-token = EAT_Tagged_Message / EAT_Untagged_Message / JWT_Message 1559 ; This is CBOR-format EAT token in the CWT or UCCS format that is a 1560 ; tag. COSE_Tagged_message is defined in RFC 8152. Tag 601 is 1561 ; proposed by the UCCS draft, but not yet assigned. 1563 EAT_Tagged_Message = #6.61(COSE_Tagged_Message) / #6.601(eat-claim-set) 1565 ; This is a CBOR-format EAT token that is a CWT or UCSS that is not a 1566 ; tag COSE_Tagged_message and COSE_Untagged_Message are defined in RFC 1567 ; 8152. 1569 EAT_Untagged_Message = COSE_Tagged_Message / COSE_Untagged_Message / UCCS_Untagged_Message 1571 ; This is an "unwrapped" UCCS tag. Unwrapping a tag means to use the 1572 ; definition of its content without the preceding type 6 tag 1573 ; integer. Since a UCCS is nothing but a tag for an unsecured CWT 1574 ; claim set, unwrapping reduces to a bare eat-claim-set. 1576 UCCS_Untagged_Message = eat-claim-set 1578 string-or-uri = tstr 1580 time-int = #6.1(int) 1581 $$eat-extension //= ( 1582 ? issuer => text, 1583 ? subject => text, 1584 ? audience => text, 1585 ? expiration => time, 1586 ? not-before => time, 1587 ? issued-at => time, 1588 ? cwt-id => bytes, 1589 ) 1591 issuer = 1 1592 subject = 2 1593 audience = 3 1594 expiration = 4 1595 not-before = 5 1596 issued-at = 6 1597 cwt-id = 7 1599 debug-status-type = &( 1600 enabled: 0, 1601 disabled: 1, 1602 disabled-since-boot: 2, 1603 disabled-permanently: 3, 1604 disabled-fully-and-permanently: 4 1605 ) 1607 debug-status-claim = ( 1608 debug-status => debug-status-type 1610 ) 1611 location-type = { 1612 latitude => number, 1613 longitude => number, 1614 ? altitude => number, 1615 ? accuracy => number, 1616 ? altitude-accuracy => number, 1617 ? heading => number, 1618 ? speed => number, 1619 ? timestamp => ~time-int, 1620 ? age => uint 1621 } 1623 latitude = 1 1624 longitude = 2 1625 altitude = 3 1626 accuracy = 4 1627 altitude-accuracy = 5 1628 heading = 6 1629 speed = 7 1630 timestamp = 8 1631 age = 9 1633 location-claim = ( 1634 location => location-type 1635 ) 1636 nonce-type = bstr .size (8..64) 1638 nonce-claim = ( 1639 nonce => nonce-type / [ 2* nonce-type ] 1640 ) 1641 oemid-claim = ( 1642 oemid => bstr 1643 ) 1644 ; copied from CoSWID 1645 ; TODO: how to properly make reference to CoSWID and have tool validate 1647 $version-scheme /= multipartnumeric 1648 $version-scheme /= multipartnumeric-suffix 1649 $version-scheme /= alphanumeric 1650 $version-scheme /= decimal 1651 $version-scheme /= semver 1652 $version-scheme /= uint / text 1653 multipartnumeric = 1 1654 multipartnumeric-suffix = 2 1655 alphanumeric = 3 1656 decimal = 4 1657 semver = 16384 1659 chip-version-claim = ( 1660 chip-version => tstr 1661 ) 1663 chip-version-scheme-claim = ( 1664 chip-version-scheme => $version-scheme 1665 ) 1667 board-version-claim = ( 1668 board-version => tstr 1669 ) 1671 board-version-scheme-claim = ( 1672 board-version-scheme => $version-scheme 1673 ) 1675 device-version-claim = ( 1676 device-version => tstr 1677 ) 1679 device-version-scheme-claim = ( 1680 device-version-scheme => $version-scheme 1681 ) 1683 ean-type = text .regexp "[0-9]{13}" 1685 ean-chip-version-claim = ( 1686 ean-chip-version => ean-type 1687 ) 1689 ean-board-version-claim = ( 1690 ean-board-version => ean-type 1691 ) 1693 ean-device-version-claim = ( 1694 ean-device-version => ean-type 1695 ) 1697 hardware-version-claims = ( 1698 ? chip-version-claim, 1699 ? board-version-claim, 1700 ? device-version-claim, 1701 ? chip-version-scheme-claim, 1702 ? board-version-scheme-claim, 1703 ? device-version-scheme-claim, 1704 ? ean-chip-version-claim, 1705 ? ean-board-version-claim, 1706 ? ean-device-version-claim, 1707 ) 1709 origination-claim = ( 1710 origination => string-or-uri 1711 ) 1712 secure-boot-claim = ( 1713 secure-boot => bool 1714 ) 1715 security-level-type = &( 1716 unrestricted: 1, 1717 restricted: 2, 1718 secure-restricted: 3, 1719 hardware: 4 1720 ) 1722 security-level-claim = ( 1723 security-level => security-level-type 1724 ) 1725 ; The part of a token that contains all the submodules. It is a peer 1726 ; with the claims in the token, but not a claim, only a map/object to 1727 ; hold all the submodules. 1729 submods-part = ( 1730 submods => submods-type 1731 ) 1733 submods-type = { + submod-type } 1735 ; The type of a submodule which can either be a nested claim set or a 1736 ; nested separately signed token. Nested tokens are wrapped in a bstr 1737 ; or a tstr. 1739 submod-type = ( 1740 submod-name => eat-claim-set / nested-token 1741 ) 1743 ; When this is a bstr, the contents are an eat-token in CWT or UCCS 1744 ; format. When this is a tstr, the contents are an eat-token in JWT 1745 ; format. 1747 nested-token = bstr / tstr; 1749 ; Each submodule has a unique text string name. 1751 submod-name = tstr 1753 ueid-type = bstr .size (7..33) 1755 ueid-claim = ( 1756 ueid => ueid-type 1757 ) 1758 intended-use-type = &( 1759 generic: 1, 1760 registration: 2, 1761 provisioning: 3, 1762 csr: 4, 1763 pop: 5 1764 ) 1766 intended-use-claim = ( 1767 intended-use => intended-use-type 1768 ) 1769 uptime-claim = ( 1770 uptime => uint 1771 ) 1772 ; The following Claim Keys (labels) are pre-assigned by IANA. 1773 ; They are for CBOR-based tokens (CWT and UCCS). 1774 ; They are not expected to change in the final publication as an RFC. 1776 nonce = 10 1777 ueid = 11 1778 oemid = 13 1779 security-level = 14 1780 secure-boot = 15 1781 debug-status = 16 1782 location = 17 1783 submods = 20 1785 ; These are not yet assigned in any way and may change. 1786 ; These are intentionally above 24 so as to not use up 1787 ; single-byte labels. 1789 origination = 1790 uptime = 1791 chip-version = 1792 board-version = 1793 device-version = 1794 chip-version-scheme = 1795 board-version-scheme = 1796 device-version-scheme = 1797 ean-chip-version = 1798 ean-board-version = 1799 ean-device-version = 1800 intended-use = 1802 ; The following are Claim Keys (labels) assigned for JSON-encoded tokens. 1804 ueid /= "ueid" 1805 nonce /= "nonce" 1806 origination /= "origination" 1807 oemid /= "oemid" 1808 security-level /= "seclevel" 1809 secure-boot /= "secboot" 1810 debug-status /= "dbgstat" 1811 location /= "location" 1812 uptime /= "uptime" 1813 profile /= "eat-profile" 1814 intended-use /= "intuse" 1815 boot-seed /= "bootseed" 1816 submods /= "submods" 1817 timestamp /= "timestamp" 1819 latitude /= "lat" 1820 longitude /= "long" 1821 altitude /= "alt" 1822 accuracy /= "accry" 1823 altitude-accuracy /= "alt-accry" 1824 heading /= "heading" 1825 speed /= "speed" 1827 7. IANA Considerations 1829 7.1. Reuse of CBOR Web Token (CWT) Claims Registry 1831 Claims defined for EAT are compatible with those of CWT so the CWT 1832 Claims Registry is re used. No new IANA registry is created. All 1833 EAT claims should be registered in the CWT and JWT Claims Registries. 1835 7.2. Claim Characteristics 1837 The following is design guidance for creating new EAT claims, 1838 particularly those to be registered with IANA. 1840 Much of this guidance is generic and could also be considered when 1841 designing new CWT or JWT claims. 1843 7.2.1. Interoperability and Relying Party Orientation 1845 It is a broad goal that EATs can be processed by relying parties in a 1846 general way regardless of the type, manufacturer or technology of the 1847 device from which they originate. It is a goal that there be 1848 general-purpose verification implementations that can verify tokens 1849 for large numbers of use cases with special cases and configurations 1850 for different device types. This is a goal of interoperability of 1851 the semantics of claims themselves, not just of the signing, encoding 1852 and serialization formats. 1854 This is a lofty goal and difficult to achieve broadly requiring 1855 careful definition of claims in a technology neutral way. Sometimes 1856 it will be difficult to design a claim that can represent the 1857 semantics of data from very different device types. However, the 1858 goal remains even when difficult. 1860 7.2.2. Operating System and Technology Neutral 1862 Claims should be defined such that they are not specific to an 1863 operating system. They should be applicable to multiple large high- 1864 level operating systems from different vendors. They should also be 1865 applicable to multiple small embedded operating systems from multiple 1866 vendors and everything in between. 1868 Claims should not be defined such that they are specific to a SW 1869 environment or programming language. 1871 Claims should not be defined such that they are specific to a chip or 1872 particular hardware. For example, they should not just be the 1873 contents of some HW status register as it is unlikely that the same 1874 HW status register with the same bits exists on a chip of a different 1875 manufacturer. 1877 The boot and debug state claims in this document are an example of a 1878 claim that has been defined in this neutral way. 1880 7.2.3. Security Level Neutral 1882 Many use cases will have EATs generated by some of the most secure 1883 hardware and software that exists. Secure Elements and smart cards 1884 are examples of this. However, EAT is intended for use in low- 1885 security use cases the same as high-security use case. For example, 1886 an app on a mobile device may generate EATs on its own. 1888 Claims should be defined and registered on the basis of whether they 1889 are useful and interoperable, not based on security level. In 1890 particular, there should be no exclusion of claims because they are 1891 just used only in low-security environments. 1893 7.2.4. Reuse of Extant Data Formats 1895 Where possible, claims should use already standardized data items, 1896 identifiers and formats. This takes advantage of the expertise put 1897 into creating those formats and improves interoperability. 1899 Often extant claims will not be defined in an encoding or 1900 serialization format used by EAT. It is preferred to define a CBOR 1901 and JSON format for them so that EAT implementations do not require a 1902 plethora of encoders and decoders for serialization formats. 1904 In some cases, it may be better to use the encoding and serialization 1905 as is. For example, signed X.509 certificates and CRLs can be 1906 carried as-is in a byte string. This retains interoperability with 1907 the extensive infrastructure for creating and processing X.509 1908 certificates and CRLs. 1910 7.2.5. Proprietary Claims 1912 EAT allows the definition and use of proprietary claims. 1914 For example, a device manufacturer may generate a token with 1915 proprietary claims intended only for verification by a service 1916 offered by that device manufacturer. This is a supported use case. 1918 In many cases proprietary claims will be the easiest and most obvious 1919 way to proceed, however for better interoperability, use of general 1920 standardized claims is preferred. 1922 7.3. Claims Registered by This Document 1924 This specification adds the following values to the "JSON Web Token 1925 Claims" registry established by [RFC7519] and the "CBOR Web Token 1926 Claims Registry" established by [RFC8392]. Each entry below is an 1927 addition to both registries (except for the nonce claim which is 1928 already registered for JWT, but not registered for CWT). 1930 The "Claim Description", "Change Controller" and "Specification 1931 Documents" are common and equivalent for the JWT and CWT registries. 1932 The "Claim Key" and "Claim Value Types(s)" are for the CWT registry 1933 only. The "Claim Name" is as defined for the CWT registry, not the 1934 JWT registry. The "JWT Claim Name" is equivalent to the "Claim Name" 1935 in the JWT registry. 1937 7.3.1. Claims for Early Assignment 1939 RFC Editor: in the final publication this section should be combined 1940 with the following section as it will no longer be necessary to 1941 distinguish claims with early assignment. Also, the following 1942 paragraph should be removed. 1944 The claims in this section have been (requested for / given) early 1945 assignment according to [RFC7120]. They have been assigned values 1946 and registered before final publication of this document. While 1947 their semantics is not expected to change in final publication, it is 1948 possible that they will. The JWT Claim Names and CWT Claim Keys are 1949 not expected to change. 1951 o Claim Name: Nonce 1953 o Claim Description: Nonce 1955 o JWT Claim Name: "nonce" (already registered for JWT) 1957 o Claim Key: 10 1959 o Claim Value Type(s): byte string 1961 o Change Controller: IESG 1963 o Specification Document(s): [OpenIDConnectCore], *this document* 1965 o Claim Name: UEID 1967 o Claim Description: The Universal Entity ID 1969 o JWT Claim Name: "ueid" 1971 o CWT Claim Key: 11 1973 o Claim Value Type(s): byte string 1975 o Change Controller: IESG 1977 o Specification Document(s): *this document* 1979 o Claim Name: OEMID 1981 o Claim Description: IEEE-based OEM ID 1983 o JWT Claim Name: "oemid" 1984 o Claim Key: 13 1986 o Claim Value Type(s): byte string 1988 o Change Controller: IESG 1990 o Specification Document(s): *this document* 1992 o Claim Name: Security Level 1994 o Claim Description: Characterization of the security of an Attester 1995 or submodule 1997 o JWT Claim Name: "seclevel" 1999 o Claim Key: 14 2001 o Claim Value Type(s): integer 2003 o Change Controller: IESG 2005 o Specification Document(s): *this document* 2007 o Claim Name: Secure Boot 2009 o Claim Description: Indicate whether the boot was secure 2011 o JWT Claim Name: "secboot" 2013 o Claim Key: 15 2015 o Claim Value Type(s): Boolean 2017 o Change Controller: IESG 2019 o Specification Document(s): *this document* 2021 o Claim Name: Debug Status 2023 o Claim Description: Indicate status of debug facilities 2025 o JWT Claim Name: "dbgstat" 2027 o Claim Key: 16 2029 o Claim Value Type(s): integer 2031 o Change Controller: IESG 2032 o Specification Document(s): *this document* 2034 o Claim Name: Location 2036 o Claim Description: The geographic location 2038 o JWT Claim Name: "location" 2040 o Claim Key: 17 2042 o Claim Value Type(s): map 2044 o Change Controller: IESG 2046 o Specification Document(s): *this document* 2048 o Claim Name: Submodules Section 2050 o Claim Description: The section containing submodules (not actually 2051 a claim) 2053 o JWT Claim Name: "submods" 2055 o Claim Key: 20 2057 o Claim Value Type(s): map 2059 o Change Controller: IESG 2061 o Specification Document(s): *this document* 2063 7.3.2. To be Assigned Claims 2065 TODO: add the rest of the claims in here 2067 8. Privacy Considerations 2069 Certain EAT claims can be used to track the owner of an entity and 2070 therefore, implementations should consider providing privacy- 2071 preserving options dependent on the intended usage of the EAT. 2072 Examples would include suppression of location claims for EAT's 2073 provided to unauthenticated consumers. 2075 8.1. UEID Privacy Considerations 2077 A UEID is usually not privacy-preserving. Any set of relying parties 2078 that receives tokens that happen to be from a single device will be 2079 able to know the tokens are all from the same device and be able to 2080 track the device. Thus, in many usage situations ueid violates 2081 governmental privacy regulation. In other usage situations UEID will 2082 not be allowed for certain products like browsers that give privacy 2083 for the end user. It will often be the case that tokens will not 2084 have a UEID for these reasons. 2086 There are several strategies that can be used to still be able to put 2087 UEID's in tokens: 2089 o The device obtains explicit permission from the user of the device 2090 to use the UEID. This may be through a prompt. It may also be 2091 through a license agreement. For example, agreements for some 2092 online banking and brokerage services might already cover use of a 2093 UEID. 2095 o The UEID is used only in a particular context or particular use 2096 case. It is used only by one relying party. 2098 o The device authenticates the relying party and generates a derived 2099 UEID just for that particular relying party. For example, the 2100 relying party could prove their identity cryptographically to the 2101 device, then the device generates a UEID just for that relying 2102 party by hashing a proofed relying party ID with the main device 2103 UEID. 2105 Note that some of these privacy preservation strategies result in 2106 multiple UEIDs per device. Each UEID is used in a different context, 2107 use case or system on the device. However, from the view of the 2108 relying party, there is just one UEID and it is still globally 2109 universal across manufacturers. 2111 8.2. Location Privacy Considerations 2113 Geographic location is most always considered personally identifiable 2114 information. Implementers should consider laws and regulations 2115 governing the transmission of location data from end user devices to 2116 servers and services. Implementers should consider using location 2117 management facilities offered by the operating system on the device 2118 generating the attestation. For example, many mobile phones prompt 2119 the user for permission when before sending location data. 2121 9. Security Considerations 2123 The security considerations provided in Section 8 of [RFC8392] and 2124 Section 11 of [RFC7519] apply to EAT in its CWT and JWT form, 2125 respectively. In addition, implementors should consider the 2126 following. 2128 9.1. Key Provisioning 2130 Private key material can be used to sign and/or encrypt the EAT, or 2131 can be used to derive the keys used for signing and/or encryption. 2132 In some instances, the manufacturer of the entity may create the key 2133 material separately and provision the key material in the entity 2134 itself. The manfuacturer of any entity that is capable of producing 2135 an EAT should take care to ensure that any private key material be 2136 suitably protected prior to provisioning the key material in the 2137 entity itself. This can require creation of key material in an 2138 enclave (see [RFC4949] for definition of "enclave"), secure 2139 transmission of the key material from the enclave to the entity using 2140 an appropriate protocol, and persistence of the private key material 2141 in some form of secure storage to which (preferably) only the entity 2142 has access. 2144 9.1.1. Transmission of Key Material 2146 Regarding transmission of key material from the enclave to the 2147 entity, the key material may pass through one or more intermediaries. 2148 Therefore some form of protection ("key wrapping") may be necessary. 2149 The transmission itself may be performed electronically, but can also 2150 be done by human courier. In the latter case, there should be 2151 minimal to no exposure of the key material to the human (e.g. 2152 encrypted portable memory). Moreover, the human should transport the 2153 key material directly from the secure enclave where it was created to 2154 a destination secure enclave where it can be provisioned. 2156 9.2. Transport Security 2158 As stated in Section 8 of [RFC8392], "The security of the CWT relies 2159 upon on the protections offered by COSE". Similar considerations 2160 apply to EAT when sent as a CWT. However, EAT introduces the concept 2161 of a nonce to protect against replay. Since an EAT may be created by 2162 an entity that may not support the same type of transport security as 2163 the consumer of the EAT, intermediaries may be required to bridge 2164 communications between the entity and consumer. As a result, it is 2165 RECOMMENDED that both the consumer create a nonce, and the entity 2166 leverage the nonce along with COSE mechanisms for encryption and/or 2167 signing to create the EAT. 2169 Similar considerations apply to the use of EAT as a JWT. Although 2170 the security of a JWT leverages the JSON Web Encryption (JWE) and 2171 JSON Web Signature (JWS) specifications, it is still recommended to 2172 make use of the EAT nonce. 2174 9.3. Multiple EAT Consumers 2176 In many cases, more than one EAT consumer may be required to fully 2177 verify the entity attestation. Examples include individual consumers 2178 for nested EATs, or consumers for individual claims with an EAT. 2179 When multiple consumers are required for verification of an EAT, it 2180 is important to minimize information exposure to each consumer. In 2181 addition, the communication between multiple consumers should be 2182 secure. 2184 For instance, consider the example of an encrypted and signed EAT 2185 with multiple claims. A consumer may receive the EAT (denoted as the 2186 "receiving consumer"), decrypt its payload, verify its signature, but 2187 then pass specific subsets of claims to other consumers for 2188 evaluation ("downstream consumers"). Since any COSE encryption will 2189 be removed by the receiving consumer, the communication of claim 2190 subsets to any downstream consumer should leverage a secure protocol 2191 (e.g.one that uses transport-layer security, i.e. TLS), 2193 However, assume the EAT of the previous example is hierarchical and 2194 each claim subset for a downstream consumer is created in the form of 2195 a nested EAT. Then transport security between the receiving and 2196 downstream consumers is not strictly required. Nevertheless, 2197 downstream consumers of a nested EAT should provide a nonce unique to 2198 the EAT they are consuming. 2200 10. References 2202 10.1. Normative References 2204 [CoSWID] "Concise Software Identification Tags", November 2020, 2205 . 2207 [EAN-13] GS1, "International Article Number - EAN/UPC barcodes", 2208 2019, . 2210 [FIDO.AROE] 2211 The FIDO Alliance, "FIDO Authenticator Allowed Restricted 2212 Operating Environments List", November 2019, 2213 . 2216 [IANA.CWT.Claims] 2217 IANA, "CBOR Web Token (CWT) Claims", 2218 . 2220 [IANA.JWT.Claims] 2221 IANA, "JSON Web Token (JWT) Claims", 2222 . 2224 [OpenIDConnectCore] 2225 Sakimura, N., Bradley, J., Jones, M., Medeiros, B. D., and 2226 C. Mortimore, "OpenID Connect Core 1.0 incorporating 2227 errata set 1", November 2014, 2228 . 2230 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2231 Requirement Levels", BCP 14, RFC 2119, 2232 DOI 10.17487/RFC2119, March 1997, 2233 . 2235 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 2236 DOI 10.17487/RFC7517, May 2015, 2237 . 2239 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 2240 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 2241 . 2243 [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- 2244 Possession Key Semantics for JSON Web Tokens (JWTs)", 2245 RFC 7800, DOI 10.17487/RFC7800, April 2016, 2246 . 2248 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2249 Writing an IANA Considerations Section in RFCs", BCP 26, 2250 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2251 . 2253 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 2254 RFC 8152, DOI 10.17487/RFC8152, July 2017, 2255 . 2257 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2258 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2259 May 2017, . 2261 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 2262 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 2263 May 2018, . 2265 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 2266 Definition Language (CDDL): A Notational Convention to 2267 Express Concise Binary Object Representation (CBOR) and 2268 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 2269 June 2019, . 2271 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 2272 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 2273 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 2274 2020, . 2276 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 2277 Representation (CBOR)", STD 94, RFC 8949, 2278 DOI 10.17487/RFC8949, December 2020, 2279 . 2281 [ThreeGPP.IMEI] 2282 3GPP, "3rd Generation Partnership Project; Technical 2283 Specification Group Core Network and Terminals; Numbering, 2284 addressing and identification", 2019, 2285 . 2288 [UCCS.Draft] 2289 Birkholz, H., "A CBOR Tag for Unprotected CWT Claims 2290 Sets", 2020, 2291 . 2293 [WGS84] National Imagery and Mapping Agency, "National Imagery and 2294 Mapping Agency Technical Report 8350.2, Third Edition", 2295 2000, . 2298 10.2. Informative References 2300 [BirthdayAttack] 2301 "Birthday attack", 2302 . 2304 [Common.Criteria] 2305 "Common Criteria for Information Technology Security 2306 Evaluation", April 2017, 2307 . 2309 [ECMAScript] 2310 "Ecma International, "ECMAScript Language Specification, 2311 5.1 Edition", ECMA Standard 262", June 2011, 2312 . 2315 [FIDO.Registry] 2316 The FIDO Alliance, "FIDO Registry of Predefined Values", 2317 December 2019, . 2320 [FIPS-140] 2321 National Institue of Standards, "Security Requirements for 2322 Cryptographic Modules", May 2001, 2323 . 2326 [IDevID] "IEEE Standard, "IEEE 802.1AR Secure Device Identifier"", 2327 December 2009, . 2330 [IEEE.802-2001] 2331 "IEEE Standard For Local And Metropolitan Area Networks 2332 Overview And Architecture", 2007, 2333 . 2336 [IEEE.RA] "IEEE Registration Authority", 2337 . 2340 [OUI.Guide] 2341 "Guidelines for Use of Extended Unique Identifier (EUI), 2342 Organizationally Unique Identifier (OUI), and Company ID 2343 (CID)", August 2017, 2344 . 2347 [OUI.Lookup] 2348 "IEEE Registration Authority Assignments", 2349 . 2352 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 2353 Unique IDentifier (UUID) URN Namespace", RFC 4122, 2354 DOI 10.17487/RFC4122, July 2005, 2355 . 2357 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 2358 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 2359 . 2361 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 2362 Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2363 2014, . 2365 [W3C.GeoLoc] 2366 Worldwide Web Consortium, "Geolocation API Specification 2367 2nd Edition", January 2018, . 2370 Appendix A. Examples 2372 A.1. Very Simple EAT 2374 This is shown in CBOR diagnostic form. Only the payload signed by 2375 COSE is shown. 2377 { 2378 / issuer / 1: "joe", 2379 / nonce / 10: h'948f8860d13a463e8e', 2380 / UEID / 11: h'0198f50a4ff6c05861c8860d13a638ea', 2381 / secure-boot / 15: true, 2382 / debug-disable / 16: 3, / permanent-disable / 2383 / timestamp (iat) / 6: 1(1526542894) 2384 } 2386 A.2. Example with Submodules, Nesting and Security Levels 2388 { 2389 / nonce / 10: h'948f8860d13a463e8e', 2390 / UEID / 11: h'0198f50a4ff6c05861c8860d13a638ea', 2391 / secure-boot / 15: true, 2392 / debug-disable / 16: 3, / permanent-disable / 2393 / timestamp (iat) / 6: 1(1526542894), 2394 / security-level / 14: 3, / secure restricted OS / 2395 / submods / 20: { 2396 / first submod, an Android Application / 2397 "Android App Foo" : { 2398 / security-level / 14: 1 / unrestricted / 2399 }, 2401 / 2nd submod, A nested EAT from a secure element / 2402 "Secure Element Eat" : 2403 / an embedded EAT, bytes of which are not shown / 2404 h'420123', 2406 / 3rd submod, information about Linux Android / 2407 "Linux Android": { 2408 / security-level / 14: 1 / unrestricted / 2409 } 2410 } 2411 } 2413 Appendix B. UEID Design Rationale 2414 B.1. Collision Probability 2416 This calculation is to determine the probability of a collision of 2417 UEIDs given the total possible entity population and the number of 2418 entities in a particular entity management database. 2420 Three different sized databases are considered. The number of 2421 devices per person roughly models non-personal devices such as 2422 traffic lights, devices in stores they shop in, facilities they work 2423 in and so on, even considering individual light bulbs. A device may 2424 have individually attested subsystems, for example parts of a car or 2425 a mobile phone. It is assumed that the largest database will have at 2426 most 10% of the world's population of devices. Note that databases 2427 that handle more than a trillion records exist today. 2429 The trillion-record database size models an easy-to-imagine reality 2430 over the next decades. The quadrillion-record database is roughly at 2431 the limit of what is imaginable and should probably be accommodated. 2432 The 100 quadrillion datadbase is highly speculative perhaps involving 2433 nanorobots for every person, livestock animal and domesticated bird. 2434 It is included to round out the analysis. 2436 Note that the items counted here certainly do not have IP address and 2437 are not individually connected to the network. They may be connected 2438 to internal buses, via serial links, Bluetooth and so on. This is 2439 not the same problem as sizing IP addresses. 2441 +---------+------------+--------------+------------+----------------+ 2442 | People | Devices / | Subsystems / | Database | Database Size | 2443 | | Person | Device | Portion | | 2444 +---------+------------+--------------+------------+----------------+ 2445 | 10 | 100 | 10 | 10% | trillion | 2446 | billion | | | | (10^12) | 2447 | 10 | 100,000 | 10 | 10% | quadrillion | 2448 | billion | | | | (10^15) | 2449 | 100 | 1,000,000 | 10 | 10% | 100 | 2450 | billion | | | | quadrillion | 2451 | | | | | (10^17) | 2452 +---------+------------+--------------+------------+----------------+ 2454 This is conceptually similar to the Birthday Problem where m is the 2455 number of possible birthdays, always 365, and k is the number of 2456 people. It is also conceptually similar to the Birthday Attack where 2457 collisions of the output of hash functions are considered. 2459 The proper formula for the collision calculation is 2460 p = 1 - e^{-k^2/(2n)} 2462 p Collision Probability 2463 n Total possible population 2464 k Actual population 2466 However, for the very large values involved here, this formula 2467 requires floating point precision higher than commonly available in 2468 calculators and SW so this simple approximation is used. See 2469 [BirthdayAttack]. 2471 p = k^2 / 2n 2473 For this calculation: 2475 p Collision Probability 2476 n Total population based on number of bits in UEID 2477 k Population in a database 2479 +----------------------+--------------+--------------+--------------+ 2480 | Database Size | 128-bit UEID | 192-bit UEID | 256-bit UEID | 2481 +----------------------+--------------+--------------+--------------+ 2482 | trillion (10^12) | 2 * 10^-15 | 8 * 10^-35 | 5 * 10^-55 | 2483 | quadrillion (10^15) | 2 * 10^-09 | 8 * 10^-29 | 5 * 10^-49 | 2484 | 100 quadrillion | 2 * 10^-05 | 8 * 10^-25 | 5 * 10^-45 | 2485 | (10^17) | | | | 2486 +----------------------+--------------+--------------+--------------+ 2488 Next, to calculate the probability of a collision occurring in one 2489 year's operation of a database, it is assumed that the database size 2490 is in a steady state and that 10% of the database changes per year. 2491 For example, a trillion record database would have 100 billion states 2492 per year. Each of those states has the above calculated probability 2493 of a collision. 2495 This assumption is a worst-case since it assumes that each state of 2496 the database is completely independent from the previous state. In 2497 reality this is unlikely as state changes will be the addition or 2498 deletion of a few records. 2500 The following tables gives the time interval until there is a 2501 probability of a collision based on there being one tenth the number 2502 of states per year as the number of records in the database. 2504 t = 1 / ((k / 10) * p) 2506 t Time until a collision 2507 p Collision probability for UEID size 2508 k Database size 2510 +---------------------+---------------+--------------+--------------+ 2511 | Database Size | 128-bit UEID | 192-bit UEID | 256-bit UEID | 2512 +---------------------+---------------+--------------+--------------+ 2513 | trillion (10^12) | 60,000 years | 10^24 years | 10^44 years | 2514 | quadrillion (10^15) | 8 seconds | 10^14 years | 10^34 years | 2515 | 100 quadrillion | 8 | 10^11 years | 10^31 years | 2516 | (10^17) | microseconds | | | 2517 +---------------------+---------------+--------------+--------------+ 2519 Clearly, 128 bits is enough for the near future thus the requirement 2520 that UEIDs be a minimum of 128 bits. 2522 There is no requirement for 256 bits today as quadrillion-record 2523 databases are not expected in the near future and because this time- 2524 to-collision calculation is a very worst case. A future update of 2525 the standard may increase the requirement to 256 bits, so there is a 2526 requirement that implementations be able to receive 256-bit UEIDs. 2528 B.2. No Use of UUID 2530 A UEID is not a UUID [RFC4122] by conscious choice for the following 2531 reasons. 2533 UUIDs are limited to 128 bits which may not be enough for some future 2534 use cases. 2536 Today, cryptographic-quality random numbers are available from common 2537 CPUs and hardware. This hardware was introduced between 2010 and 2538 2015. Operating systems and cryptographic libraries give access to 2539 this hardware. Consequently, there is little need for 2540 implementations to construct such random values from multiple sources 2541 on their own. 2543 Version 4 UUIDs do allow for use of such cryptographic-quality random 2544 numbers, but do so by mapping into the overall UUID structure of time 2545 and clock values. This structure is of no value here yet adds 2546 complexity. It also slightly reduces the number of actual bits with 2547 entropy. 2549 UUIDs seem to have been designed for scenarios where the implementor 2550 does not have full control over the environment and uniqueness has to 2551 be constructed from identifiers at hand. UEID takes the view that 2552 hardware, software and/or manufacturing process directly implement 2553 UEID in a simple and direct way. It takes the view that 2554 cryptographic quality random number generators are readily available 2555 as they are implemented in commonly used CPU hardware. 2557 Appendix C. Changes from Previous Drafts 2559 The following is a list of known changes from the previous drafts. 2560 This list is non-authoritative. It is meant to help reviewers see 2561 the significant differences. 2563 C.1. From draft-rats-eat-01 2565 o Added UEID design rationale appendix 2567 C.2. From draft-mandyam-rats-eat-00 2569 This is a fairly large change in the orientation of the document, but 2570 no new claims have been added. 2572 o Separate information and data model using CDDL. 2574 o Say an EAT is a CWT or JWT 2576 o Use a map to structure the boot_state and location claims 2578 C.3. From draft-ietf-rats-eat-01 2580 o Clarifications and corrections for OEMID claim 2582 o Minor spelling and other fixes 2584 o Add the nonce claim, clarify jti claim 2586 C.4. From draft-ietf-rats-eat-02 2588 o Roll all EUIs back into one UEID type 2590 o UEIDs can be one of three lengths, 128, 192 and 256. 2592 o Added appendix justifying UEID design and size. 2594 o Submods part now includes nested eat tokens so they can be named 2595 and there can be more tha one of them 2597 o Lots of fixes to the CDDL 2599 o Added security considerations 2601 C.5. From draft-ietf-rats-eat-03 2603 o Split boot_state into secure-boot and debug-disable claims 2605 o Debug disable is an enumerated type rather than Booleans 2607 C.6. From draft-ietf-rats-eat-04 2609 o Change IMEI-based UEIDs to be encoded as a 14-byte string 2611 o CDDL cleaned up some more 2613 o CDDL allows for JWTs and UCCSs 2615 o CWT format submodules are byte string wrapped 2617 o Allows for JWT nested in CWT and vice versa 2619 o Allows UCCS (unsigned CWTs) and JWT unsecured tokens 2621 o Clarify tag usage when nesting tokens 2623 o Add section on key inclusion 2625 o Add hardware version claims 2627 o Collected CDDL is now filled in. Other CDDL corrections. 2629 o Rename debug-disable to debug-status; clarify that it is not 2630 extensible 2632 o Security level claim is not extensible 2634 o Improve specification of location claim and added a location 2635 privacy section 2637 o Add intended use claim 2639 C.7. From draft-ietf-rats-05 2641 o CDDL format issues resolved 2643 o Corrected reference to Location Privacy section 2645 C.8. From draft-ietf-rats-06 2647 o Added boot-seed claim 2649 o Rework CBOR interoperability section 2651 o Added profiles claim and section 2653 C.9. From draft-ietf-rats-07 2655 o Filled in IANA and other sections for possible preassignment of 2656 claim keys for well understood claims 2658 Authors' Addresses 2660 Giridhar Mandyam 2661 Qualcomm Technologies Inc. 2662 5775 Morehouse Drive 2663 San Diego, California 2664 USA 2666 Phone: +1 858 651 7200 2667 EMail: mandyam@qti.qualcomm.com 2669 Laurence Lundblade 2670 Security Theory LLC 2672 EMail: lgl@island-resort.com 2674 Miguel Ballesteros 2675 Qualcomm Technologies Inc. 2676 5775 Morehouse Drive 2677 San Diego, California 2678 USA 2680 Phone: +1 858 651 4299 2681 EMail: mballest@qti.qualcomm.com 2682 Jeremy O'Donoghue 2683 Qualcomm Technologies Inc. 2684 279 Farnborough Road 2685 Farnborough GU14 7LS 2686 United Kingdom 2688 Phone: +44 1252 363189 2689 EMail: jodonogh@qti.qualcomm.com