draft-ietf-rats-eat-09.txt   draft-ietf-rats-eat-10.txt 
RATS Working Group G. Mandyam RATS Working Group G. Mandyam
Internet-Draft Qualcomm Technologies Inc. Internet-Draft Qualcomm Technologies Inc.
Intended status: Standards Track L. Lundblade Intended status: Standards Track L. Lundblade
Expires: September 6, 2021 Security Theory LLC Expires: December 9, 2021 Security Theory LLC
M. Ballesteros M. Ballesteros
J. O'Donoghue J. O'Donoghue
Qualcomm Technologies Inc. Qualcomm Technologies Inc.
March 05, 2021 June 07, 2021
The Entity Attestation Token (EAT) The Entity Attestation Token (EAT)
draft-ietf-rats-eat-09 draft-ietf-rats-eat-10
Abstract Abstract
An Entity Attestation Token (EAT) provides a signed (attested) set of An Entity Attestation Token (EAT) provides a signed (attested) set of
claims that describe state and characteristics of an entity, claims that describe state and characteristics of an entity,
typically a device like a phone or an IoT device. These claims are typically a device like a phone or an IoT device. These claims are
used by a relying party to determine how much it wishes to trust the used by a relying party to determine how much it wishes to trust the
entity. entity.
An EAT is either a CWT or JWT with some attestation-oriented claims. An EAT is either a CWT or JWT with some attestation-oriented claims.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2021. This Internet-Draft will expire on December 9, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. CWT, JWT and UCCS . . . . . . . . . . . . . . . . . . . . 5 1.1. CWT, JWT and UCCS . . . . . . . . . . . . . . . . . . . . 6
1.2. CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Entity Overview . . . . . . . . . . . . . . . . . . . . . 6 1.3. Entity Overview . . . . . . . . . . . . . . . . . . . . . 6
1.4. EAT Operating Models . . . . . . . . . . . . . . . . . . 6 1.4. Use as Evidence and Attestation Results . . . . . . . . . 7
1.5. What is Not Standardized . . . . . . . . . . . . . . . . 8 1.5. EAT Operating Models . . . . . . . . . . . . . . . . . . 7
1.5.1. Transmission Protocol . . . . . . . . . . . . . . . . 8 1.6. What is Not Standardized . . . . . . . . . . . . . . . . 9
1.5.2. Signing Scheme . . . . . . . . . . . . . . . . . . . 8 1.6.1. Transmission Protocol . . . . . . . . . . . . . . . . 9
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.6.2. Signing Scheme . . . . . . . . . . . . . . . . . . . 9
3. The Claims . . . . . . . . . . . . . . . . . . . . . . . . . 9 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Token ID Claim (cti and jti) . . . . . . . . . . . . . . 10 3. The Claims . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Timestamp claim (iat) . . . . . . . . . . . . . . . . . . 10 3.1. Token ID Claim (cti and jti) . . . . . . . . . . . . . . 11
3.3. Nonce Claim (nonce) . . . . . . . . . . . . . . . . . . . 11 3.2. Timestamp claim (iat) . . . . . . . . . . . . . . . . . . 11
3.3.1. nonce CDDL . . . . . . . . . . . . . . . . . . . . . 11 3.3. Nonce Claim (nonce) . . . . . . . . . . . . . . . . . . . 12
3.4. Universal Entity ID Claim (ueid) . . . . . . . . . . . . 11 3.3.1. nonce CDDL . . . . . . . . . . . . . . . . . . . . . 12
3.4.1. ueid CDDL . . . . . . . . . . . . . . . . . . . . . . 13 3.4. Universal Entity ID Claim (ueid) . . . . . . . . . . . . 12
3.5. Origination Claim (origination) . . . . . . . . . . . . . 13 3.4.1. ueid CDDL . . . . . . . . . . . . . . . . . . . . . . 15
3.5.1. origination CDDL . . . . . . . . . . . . . . . . . . 14 3.5. Semi-permanent UEIDs (SUEIDs) . . . . . . . . . . . . . . 15
3.6. OEM Identification by IEEE (oemid) . . . . . . . . . . . 14 3.6. OEM Identification by IEEE (oemid) . . . . . . . . . . . 16
3.6.1. oemid CDDL . . . . . . . . . . . . . . . . . . . . . 15 3.6.1. oemid CDDL . . . . . . . . . . . . . . . . . . . . . 16
3.7. Hardware Version Claims (hardware-version-claims) . . . . 15 3.7. Hardware Version Claims (hardware-version-claims) . . . . 16
3.8. Software Description and Version . . . . . . . . . . . . 16 3.8. Software Description and Version . . . . . . . . . . . . 17
3.9. The Security Level Claim (security-level) . . . . . . . . 16 3.9. The Security Level Claim (security-level) . . . . . . . . 17
3.9.1. security-level CDDL . . . . . . . . . . . . . . . . . 17 3.9.1. security-level CDDL . . . . . . . . . . . . . . . . . 18
3.10. Secure Boot Claim (secure-boot) . . . . . . . . . . . . . 18 3.10. Secure Boot Claim (secure-boot) . . . . . . . . . . . . . 19
3.10.1. secure-boot CDDL . . . . . . . . . . . . . . . . . . 18 3.10.1. secure-boot CDDL . . . . . . . . . . . . . . . . . . 19
3.11. Debug Status Claim (debug-status) . . . . . . . . . . . . 18 3.11. Debug Status Claim (debug-status) . . . . . . . . . . . . 19
3.11.1. Enabled . . . . . . . . . . . . . . . . . . . . . . 19 3.11.1. Enabled . . . . . . . . . . . . . . . . . . . . . . 20
3.11.2. Disabled . . . . . . . . . . . . . . . . . . . . . . 19 3.11.2. Disabled . . . . . . . . . . . . . . . . . . . . . . 21
3.11.3. Disabled Since Boot . . . . . . . . . . . . . . . . 19 3.11.3. Disabled Since Boot . . . . . . . . . . . . . . . . 21
3.11.4. Disabled Permanently . . . . . . . . . . . . . . . . 19 3.11.4. Disabled Permanently . . . . . . . . . . . . . . . . 21
3.11.5. Disabled Fully and Permanently . . . . . . . . . . . 20 3.11.5. Disabled Fully and Permanently . . . . . . . . . . . 21
3.11.6. debug-status CDDL . . . . . . . . . . . . . . . . . 20 3.11.6. debug-status CDDL . . . . . . . . . . . . . . . . . 21
3.12. Including Keys . . . . . . . . . . . . . . . . . . . . . 20 3.12. Including Keys . . . . . . . . . . . . . . . . . . . . . 22
3.13. The Location Claim (location) . . . . . . . . . . . . . . 21 3.13. The Location Claim (location) . . . . . . . . . . . . . . 22
3.13.1. location CDDL . . . . . . . . . . . . . . . . . . . 21 3.13.1. location CDDL . . . . . . . . . . . . . . . . . . . 23
3.14. The Uptime Claim (uptime) . . . . . . . . . . . . . . . . 22 3.14. The Uptime Claim (uptime) . . . . . . . . . . . . . . . . 24
3.14.1. uptime CDDL . . . . . . . . . . . . . . . . . . . . 22 3.14.1. uptime CDDL . . . . . . . . . . . . . . . . . . . . 24
3.14.2. The Boot Seed Claim (boot-seed) . . . . . . . . . . 22 3.15. The Boot Seed Claim (boot-seed) . . . . . . . . . . . . . 24
3.15. The Intended Use Claim (intended-use) . . . . . . . . . . 23 3.16. The Intended Use Claim (intended-use) . . . . . . . . . . 24
3.15.1. intended-use CDDL . . . . . . . . . . . . . . . . . 23 3.16.1. intended-use CDDL . . . . . . . . . . . . . . . . . 25
3.16. The Profile Claim (profile) . . . . . . . . . . . . . . . 24 3.17. The Profile Claim (profile) . . . . . . . . . . . . . . . 25
3.17. The Submodules Part of a Token (submods) . . . . . . . . 24 3.18. The Software Manifests Claim (manifests) . . . . . . . . 26
3.17.1. Two Types of Submodules . . . . . . . . . . . . . . 25 3.19. The Software Evidence Claim {swevidence} . . . . . . . . 27
3.17.1.1. Non-token Submodules . . . . . . . . . . . . . . 25 3.20. The Submodules Part of a Token (submods) . . . . . . . . 28
3.17.1.2. Nested EATs . . . . . . . . . . . . . . . . . . 25 3.20.1. Two Types of Submodules . . . . . . . . . . . . . . 28
3.17.1.3. Unsecured JWTs and UCCS Tokens as Submodules . . 26 3.20.1.1. Non-token Submodules . . . . . . . . . . . . . . 29
3.17.2. No Inheritance . . . . . . . . . . . . . . . . . . . 27 3.20.1.2. Nested EATs . . . . . . . . . . . . . . . . . . 29
3.17.3. Security Levels . . . . . . . . . . . . . . . . . . 27 3.20.1.3. Unsecured JWTs and UCCS Tokens as Submodules . . 30
3.17.4. Submodule Names . . . . . . . . . . . . . . . . . . 27 3.20.2. No Inheritance . . . . . . . . . . . . . . . . . . . 30
3.17.5. submods CDDL . . . . . . . . . . . . . . . . . . . . 27 3.20.3. Security Levels . . . . . . . . . . . . . . . . . . 31
4. Endorsements and Verification Keys . . . . . . . . . . . . . 28 3.20.4. Submodule Names . . . . . . . . . . . . . . . . . . 31
5. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.20.5. submods CDDL . . . . . . . . . . . . . . . . . . . . 31
5.1. List of Profile Issues . . . . . . . . . . . . . . . . . 29 4. Endorsements and Verification Keys . . . . . . . . . . . . . 32
5.1.1. Use of JSON, CBOR or both . . . . . . . . . . . . . . 29 4.1. Identification Methods . . . . . . . . . . . . . . . . . 33
5.1.2. CBOR Map and Array Encoding . . . . . . . . . . . . . 29 4.1.1. COSE/JWS Key ID . . . . . . . . . . . . . . . . . . . 33
5.1.3. CBOR String Encoding . . . . . . . . . . . . . . . . 29 4.1.2. JWS and COSE X.509 Header Parameters . . . . . . . . 34
5.1.4. COSE/JOSE Protection . . . . . . . . . . . . . . . . 29 4.1.3. CBOR Certificate COSE Header Parameters . . . . . . . 34
5.1.5. COSE/JOSE Algorithms . . . . . . . . . . . . . . . . 30 4.1.4. Claim-Based Key Identification . . . . . . . . . . . 34
5.1.6. Verification Key Identification . . . . . . . . . . . 30 4.2. Other Considerations . . . . . . . . . . . . . . . . . . 34
5.1.7. Endorsement Identification . . . . . . . . . . . . . 30 5. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1.8. Required Claims . . . . . . . . . . . . . . . . . . . 30 5.1. Format of a Profile Document . . . . . . . . . . . . . . 35
5.1.9. Prohibited Claims . . . . . . . . . . . . . . . . . . 30 5.2. List of Profile Issues . . . . . . . . . . . . . . . . . 35
5.1.10. Additional Claims . . . . . . . . . . . . . . . . . . 31 5.2.1. Use of JSON, CBOR or both . . . . . . . . . . . . . . 35
5.1.11. Refined Claim Definition . . . . . . . . . . . . . . 31 5.2.2. CBOR Map and Array Encoding . . . . . . . . . . . . . 35
5.1.12. CBOR Tags . . . . . . . . . . . . . . . . . . . . . . 31 5.2.3. CBOR String Encoding . . . . . . . . . . . . . . . . 36
6. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.2.4. CBOR Preferred Serialization . . . . . . . . . . . . 36
6.1. Common CDDL Types . . . . . . . . . . . . . . . . . . . . 31 5.2.5. COSE/JOSE Protection . . . . . . . . . . . . . . . . 36
6.2. CDDL for CWT-defined Claims . . . . . . . . . . . . . . . 31 5.2.6. COSE/JOSE Algorithms . . . . . . . . . . . . . . . . 36
6.3. JSON . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.2.7. Verification Key Identification . . . . . . . . . . . 37
6.3.1. JSON Labels . . . . . . . . . . . . . . . . . . . . . 32 5.2.8. Endorsement Identification . . . . . . . . . . . . . 37
6.3.2. JSON Interoperability . . . . . . . . . . . . . . . . 33 5.2.9. Freshness . . . . . . . . . . . . . . . . . . . . . . 37
6.4. CBOR . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.2.10. Required Claims . . . . . . . . . . . . . . . . . . . 37
6.4.1. CBOR Interoperability . . . . . . . . . . . . . . . . 33 5.2.11. Prohibited Claims . . . . . . . . . . . . . . . . . . 37
6.4.1.1. EAT Constrained Device Serialization . . . . . . 33 5.2.12. Additional Claims . . . . . . . . . . . . . . . . . . 37
6.5. Collected CDDL . . . . . . . . . . . . . . . . . . . . . 34 5.2.13. Refined Claim Definition . . . . . . . . . . . . . . 37
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 5.2.14. CBOR Tags . . . . . . . . . . . . . . . . . . . . . . 38
7.1. Reuse of CBOR Web Token (CWT) Claims Registry . . . . . . 40 5.2.15. Manifests and Software Evidence Claims . . . . . . . 38
7.2. Claim Characteristics . . . . . . . . . . . . . . . . . . 40 6. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.2.1. Interoperability and Relying Party Orientation . . . 41 6.1. Common CDDL Types . . . . . . . . . . . . . . . . . . . . 38
7.2.2. Operating System and Technology Neutral . . . . . . . 41 6.2. CDDL for CWT-defined Claims . . . . . . . . . . . . . . . 38
7.2.3. Security Level Neutral . . . . . . . . . . . . . . . 41 6.3. JSON . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.2.4. Reuse of Extant Data Formats . . . . . . . . . . . . 42 6.3.1. JSON Labels . . . . . . . . . . . . . . . . . . . . . 39
7.2.5. Proprietary Claims . . . . . . . . . . . . . . . . . 42 6.3.2. JSON Interoperability . . . . . . . . . . . . . . . . 40
7.3. Claims Registered by This Document . . . . . . . . . . . 42 6.4. CBOR . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.3.1. Claims for Early Assignment . . . . . . . . . . . . . 43 6.4.1. CBOR Interoperability . . . . . . . . . . . . . . . . 41
7.3.2. To be Assigned Claims . . . . . . . . . . . . . . . . 46 6.4.1.1. EAT Constrained Device Serialization . . . . . . 41
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 46 6.5. Collected CDDL . . . . . . . . . . . . . . . . . . . . . 42
8.1. UEID Privacy Considerations . . . . . . . . . . . . . . . 46 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
8.2. Location Privacy Considerations . . . . . . . . . . . . . 47 7.1. Reuse of CBOR Web Token (CWT) Claims Registry . . . . . . 47
9. Security Considerations . . . . . . . . . . . . . . . . . . . 47 7.2. Claim Characteristics . . . . . . . . . . . . . . . . . . 48
9.1. Key Provisioning . . . . . . . . . . . . . . . . . . . . 47 7.2.1. Interoperability and Relying Party Orientation . . . 48
9.1.1. Transmission of Key Material . . . . . . . . . . . . 47 7.2.2. Operating System and Technology Neutral . . . . . . . 48
9.2. Transport Security . . . . . . . . . . . . . . . . . . . 48 7.2.3. Security Level Neutral . . . . . . . . . . . . . . . 49
9.3. Multiple EAT Consumers . . . . . . . . . . . . . . . . . 48 7.2.4. Reuse of Extant Data Formats . . . . . . . . . . . . 49
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 7.2.5. Proprietary Claims . . . . . . . . . . . . . . . . . 49
10.1. Normative References . . . . . . . . . . . . . . . . . . 49 7.3. Claims Registered by This Document . . . . . . . . . . . 49
10.2. Informative References . . . . . . . . . . . . . . . . . 51 7.3.1. Claims for Early Assignment . . . . . . . . . . . . . 50
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 53 7.3.2. To be Assigned Claims . . . . . . . . . . . . . . . . 53
A.1. Very Simple EAT . . . . . . . . . . . . . . . . . . . . . 53 7.3.3. Version Schemes Registered by this Document . . . . . 53
A.2. Example with Submodules, Nesting and Security Levels . . 53 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 53
Appendix B. UEID Design Rationale . . . . . . . . . . . . . . . 53 8.1. UEID and SUEID Privacy Considerations . . . . . . . . . . 53
B.1. Collision Probability . . . . . . . . . . . . . . . . . . 54 8.2. Location Privacy Considerations . . . . . . . . . . . . . 54
B.2. No Use of UUID . . . . . . . . . . . . . . . . . . . . . 56 9. Security Considerations . . . . . . . . . . . . . . . . . . . 54
Appendix C. Changes from Previous Drafts . . . . . . . . . . . . 57 9.1. Key Provisioning . . . . . . . . . . . . . . . . . . . . 55
C.1. From draft-rats-eat-01 . . . . . . . . . . . . . . . . . 57 9.1.1. Transmission of Key Material . . . . . . . . . . . . 55
C.2. From draft-mandyam-rats-eat-00 . . . . . . . . . . . . . 57 9.2. Transport Security . . . . . . . . . . . . . . . . . . . 55
C.3. From draft-ietf-rats-eat-01 . . . . . . . . . . . . . . . 57 9.3. Multiple EAT Consumers . . . . . . . . . . . . . . . . . 56
C.4. From draft-ietf-rats-eat-02 . . . . . . . . . . . . . . . 57 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
C.5. From draft-ietf-rats-eat-03 . . . . . . . . . . . . . . . 58 10.1. Normative References . . . . . . . . . . . . . . . . . . 56
C.6. From draft-ietf-rats-eat-04 . . . . . . . . . . . . . . . 58 10.2. Informative References . . . . . . . . . . . . . . . . . 59
C.7. From draft-ietf-rats-05 . . . . . . . . . . . . . . . . . 58 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 61
C.8. From draft-ietf-rats-06 . . . . . . . . . . . . . . . . . 59 A.1. Very Simple EAT . . . . . . . . . . . . . . . . . . . . . 61
C.9. From draft-ietf-rats-07 . . . . . . . . . . . . . . . . . 59 A.2. Example with Submodules, Nesting and Security Levels . . 61
C.10. From draft-ietf-rats-08 . . . . . . . . . . . . . . . . . 59 Appendix B. UEID Design Rationale . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 B.1. Collision Probability . . . . . . . . . . . . . . . . . . 62
B.2. No Use of UUID . . . . . . . . . . . . . . . . . . . . . 64
Appendix C. EAT Relation to IEEE.802.1AR Secure Device Identity
(DevID) . . . . . . . . . . . . . . . . . . . . . . 65
C.1. DevID Used With EAT . . . . . . . . . . . . . . . . . . . 65
C.2. How EAT Provides an Equivalent Secure Device Identity . . 66
C.3. An X.509 Format EAT . . . . . . . . . . . . . . . . . . . 66
C.4. Device Identifier Permanence . . . . . . . . . . . . . . 67
Appendix D. Changes from Previous Drafts . . . . . . . . . . . . 67
D.1. From draft-rats-eat-01 . . . . . . . . . . . . . . . . . 67
D.2. From draft-mandyam-rats-eat-00 . . . . . . . . . . . . . 67
D.3. From draft-ietf-rats-eat-01 . . . . . . . . . . . . . . . 67
D.4. From draft-ietf-rats-eat-02 . . . . . . . . . . . . . . . 68
D.5. From draft-ietf-rats-eat-03 . . . . . . . . . . . . . . . 68
D.6. From draft-ietf-rats-eat-04 . . . . . . . . . . . . . . . 68
D.7. From draft-ietf-rats-05 . . . . . . . . . . . . . . . . . 69
D.8. From draft-ietf-rats-06 . . . . . . . . . . . . . . . . . 69
D.9. From draft-ietf-rats-07 . . . . . . . . . . . . . . . . . 69
D.10. From draft-ietf-rats-08 . . . . . . . . . . . . . . . . . 69
D.11. From draft-ietf-rats-09 . . . . . . . . . . . . . . . . . 69
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 70
1. Introduction 1. Introduction
Remote device attestation is a fundamental service that allows a Remote device attestation is a fundamental service that allows a
remote device such as a mobile phone, an Internet-of-Things (IoT) remote device such as a mobile phone, an Internet-of-Things (IoT)
device, or other endpoint to prove itself to a relying party, a device, or other endpoint to prove itself to a relying party, a
server or a service. This allows the relying party to know some server or a service. This allows the relying party to know some
characteristics about the device and decide whether it trusts the characteristics about the device and decide whether it trusts the
device. device.
skipping to change at page 5, line 31 skipping to change at page 6, line 5
o Proof of the make and model of the device processor, particularly o Proof of the make and model of the device processor, particularly
for security-oriented chips for security-oriented chips
o Measurement of the software (SW) running on the device o Measurement of the software (SW) running on the device
o Configuration and state of the device o Configuration and state of the device
o Environmental characteristics of the device such as its GPS o Environmental characteristics of the device such as its GPS
location location
TODO: mention use for Attestation Evidence and Results.
1.1. CWT, JWT and UCCS 1.1. CWT, JWT and UCCS
For flexibility and ease of imlpementation in a wide variety of For flexibility and ease of imlpementation in a wide variety of
environments, EATs can be either CBOR [RFC8949] or JSON [ECMAScript] environments, EATs can be either CBOR [RFC8949] or JSON [ECMAScript]
format. This specification simultaneously describes both formats. format. This specification simultaneously describes both formats.
An EAT is either a CWT as defined in [RFC8392], a UCCS as defined in An EAT is either a CWT as defined in [RFC8392], a UCCS as defined in
[UCCS.Draft], or a JWT as defined in [RFC7519]. This specification [UCCS.Draft], or a JWT as defined in [RFC7519]. This specification
extends those specifications with additional claims for attestation. extends those specifications with additional claims for attestation.
skipping to change at page 6, line 27 skipping to change at page 6, line 44
The CWT specification was authored before CDDL was available and did The CWT specification was authored before CDDL was available and did
not use it. This specification includes a CDDL definition of most of not use it. This specification includes a CDDL definition of most of
what is described in [RFC8392]. what is described in [RFC8392].
1.3. Entity Overview 1.3. Entity Overview
An "entity" can be any device or device subassembly ("submodule") An "entity" can be any device or device subassembly ("submodule")
that can generate its own attestation in the form of an EAT. The that can generate its own attestation in the form of an EAT. The
attestation should be cryptographically verifiable by the EAT attestation should be cryptographically verifiable by the EAT
consumer. An EAT at the device-level can be composed of several consumer. An EAT at the device-level can be composed of several
submodule EAT's. It is assumed that any entity that can create an submodule EAT's.
EAT does so by means of a dedicated root-of-trust (RoT).
Modern devices such as a mobile phone have many different execution Modern devices such as a mobile phone have many different execution
environments operating with different security levels. For example, environments operating with different security levels. For example,
it is common for a mobile phone to have an "apps" environment that it is common for a mobile phone to have an "apps" environment that
runs an operating system (OS) that hosts a plethora of downloadable runs an operating system (OS) that hosts a plethora of downloadable
apps. It may also have a TEE (Trusted Execution Environment) that is apps. It may also have a TEE (Trusted Execution Environment) that is
distinct, isolated, and hosts security-oriented functionality like distinct, isolated, and hosts security-oriented functionality like
biometric authentication. Additionally, it may have an eSE (embedded biometric authentication. Additionally, it may have an eSE (embedded
Secure Element) - a high security chip with defenses against HW Secure Element) - a high security chip with defenses against HW
attacks that can serve as a RoT. This device attestation format attacks that is used to produce attestations. This device
allows the attested data to be tagged at a security level from which attestation format allows the attested data to be tagged at a
it originates. In general, any discrete execution environment that security level from which it originates. In general, any discrete
has an identifiable security level can be considered an entity. execution environment that has an identifiable security level can be
considered an entity.
1.4. EAT Operating Models 1.4. Use as Evidence and Attestation Results
Here, normative reference is made to [RATS-Architecture],
particularly the definition of Evidence, the Verifier, Attestation
Results and the Relying Party. Per Figure 1 in [RATS-Architecture],
Evidence is a protocol message that goes from the Attester to the
Verifier and Attestation Results a message that goes from the
Verifier to the Relying Party. EAT is defined such that it can be
used to represent either Evidence, Attestation Results or both. No
claims defined here are considered exclusive to or are prohibited in
either use. It is useful to create EAT profiles as described in
Section 5 for either use.
It is useful to characterize the relationship of claims in Evidence
to those in Attestation Results.
Many claims in Evidence simply will pass through the Verifier to the
Relying Party without modification. They will be verified as
authentic from the device by the Verifier just through normal
verification of the Attester's signature. They will be protected
from modification when they are conveyed to the Relying Party by
whatever means is used to protect Attestation Results. (The details
of that protection are out of scope of this document.)
Some claims in Evidence will be verified by the Verifier by
comparison to Reference Values. In this case the claims in Evidence
will not likely be conveyed to the Relying Party. Instead, some
claim indicating they were checked may be added to the Attestation
Results or it may be tacitly known that the Verifier always does this
check.
In some cases the Verifier may provide privacy-preserving
functionality by stripping or modifying claims that do not posses
sufficient privacy-preserving characteristics.
1.5. EAT Operating Models
TODO: Rewrite (or eliminate) this section in light of the RATS TODO: Rewrite (or eliminate) this section in light of the RATS
architecture draft. architecture draft.
At least the following three participants exist in all EAT operating At least the following three participants exist in all EAT operating
models. Some operating models have additional participants. models. Some operating models have additional participants.
The Entity. This is the phone, the IoT device, the sensor, the sub- The Entity. This is the phone, the IoT device, the sensor, the sub-
assembly or such that the attestation provides information about. assembly or such that the attestation provides information about.
skipping to change at page 8, line 7 skipping to change at page 9, line 12
operating models to generally facilitate deployment and to allow for operating models to generally facilitate deployment and to allow for
some special scenarios. One special scenario has a validation some special scenarios. One special scenario has a validation
service that is monetized, most likely by the manufacturer. In service that is monetized, most likely by the manufacturer. In
another, a privacy proxy service processes the EAT before it is another, a privacy proxy service processes the EAT before it is
transmitted to the relying party. In yet another, symmetric key transmitted to the relying party. In yet another, symmetric key
material is used for signing. In this case the manufacturer should material is used for signing. In this case the manufacturer should
perform the verification, because any release of the key material perform the verification, because any release of the key material
would enable a participant other than the entity to create valid would enable a participant other than the entity to create valid
signed EATs. signed EATs.
1.5. What is Not Standardized 1.6. What is Not Standardized
The following is not standardized for EAT, just the same they are not The following is not standardized for EAT, just the same they are not
standardized for CWT or JWT. standardized for CWT or JWT.
1.5.1. Transmission Protocol 1.6.1. Transmission Protocol
EATs may be transmitted by any protocol the same as CWTs and JWTs. EATs may be transmitted by any protocol the same as CWTs and JWTs.
For example, they might be added in extension fields of other For example, they might be added in extension fields of other
protocols, bundled into an HTTP header, or just transmitted as files. protocols, bundled into an HTTP header, or just transmitted as files.
This flexibility is intentional to allow broader adoption. This This flexibility is intentional to allow broader adoption. This
flexibility is possible because EAT's are self-secured with signing flexibility is possible because EAT's are self-secured with signing
(and possibly additionally with encryption and anti-replay). The (and possibly additionally with encryption and anti-replay). The
transmission protocol is not required to fulfill any additional transmission protocol is not required to fulfill any additional
security requirements. security requirements.
For certain devices, a direct connection may not exist between the For certain devices, a direct connection may not exist between the
EAT-producing device and the Relying Party. In such cases, the EAT EAT-producing device and the Relying Party. In such cases, the EAT
should be protected against malicious access. The use of COSE and should be protected against malicious access. The use of COSE and
JOSE allows for signing and encryption of the EAT. Therefore, even JOSE allows for signing and encryption of the EAT. Therefore, even
if the EAT is conveyed through intermediaries between the device and if the EAT is conveyed through intermediaries between the device and
Relying Party, such intermediaries cannot easily modify the EAT Relying Party, such intermediaries cannot easily modify the EAT
payload or alter the signature. payload or alter the signature.
1.5.2. Signing Scheme 1.6.2. Signing Scheme
The term "signing scheme" is used to refer to the system that The term "signing scheme" is used to refer to the system that
includes end-end process of establishing signing attestation key includes end-end process of establishing signing attestation key
material in the entity, signing the EAT, and verifying it. This material in the entity, signing the EAT, and verifying it. This
might involve key IDs and X.509 certificate chains or something might involve key IDs and X.509 certificate chains or something
similar but different. The term "signing algorithm" refers just to similar but different. The term "signing algorithm" refers just to
the algorithm ID in the COSE signing structure. No particular the algorithm ID in the COSE signing structure. No particular
signing algorithm or signing scheme is required by this standard. signing algorithm or signing scheme is required by this standard.
There are three main implementation issues driving this. First, There are three main implementation issues driving this. First,
skipping to change at page 9, line 33 skipping to change at page 10, line 36
Claim Value. The value portion of the claim. A claim value can be Claim Value. The value portion of the claim. A claim value can be
any CBOR data item or JSON value. any CBOR data item or JSON value.
CWT Claims Set. The CBOR map or JSON object that contains the claims CWT Claims Set. The CBOR map or JSON object that contains the claims
conveyed by the CWT or JWT. conveyed by the CWT or JWT.
Attestation Key Material (AKM). The key material used to sign the Attestation Key Material (AKM). The key material used to sign the
EAT token. If it is done symmetrically with HMAC, then this is a EAT token. If it is done symmetrically with HMAC, then this is a
simple symmetric key. If it is done with ECC, such as an IEEE simple symmetric key. If it is done with ECC, such as an IEEE
DevID [IDevID], then this is the private part of the EC key pair. DevID [IEEE.802.1AR], then this is the private part of the EC key
If ECDAA is used, (e.g., as used by Enhanced Privacy ID, i.e. pair. If ECDAA is used, (e.g., as used by Enhanced Privacy ID,
EPID) then it is the key material needed for ECDAA. i.e. EPID) then it is the key material needed for ECDAA.
3. The Claims 3. The Claims
This section describes new claims defined for attestation. It also This section describes new claims defined for attestation. It also
mentions several claims defined by CWT and JWT that are particularly mentions several claims defined by CWT and JWT that are particularly
important for EAT. important for EAT.
Note also: * Any claim defined for CWT or JWT may be used in an EAT Note also: * Any claim defined for CWT or JWT may be used in an EAT
including those in the CWT [IANA.CWT.Claims] and JWT IANA including those in the CWT [IANA.CWT.Claims] and JWT IANA
[IANA.JWT.Claims] claims registries. [IANA.JWT.Claims] claims registries.
skipping to change at page 10, line 17 skipping to change at page 11, line 21
may be the implementation not supporting the claim, an inability to may be the implementation not supporting the claim, an inability to
determine its value, or a preference to report in a different way determine its value, or a preference to report in a different way
such as a proprietary claim. such as a proprietary claim.
CDDL along with text descriptions is used to define each claim CDDL along with text descriptions is used to define each claim
indepdent of encoding. Each claim is defined as a CDDL group (the indepdent of encoding. Each claim is defined as a CDDL group (the
group is a general aggregation and type definition feature of CDDL). group is a general aggregation and type definition feature of CDDL).
In the encoding section Section 6, the CDDL groups turn into CBOR map In the encoding section Section 6, the CDDL groups turn into CBOR map
entries and JSON name/value pairs. entries and JSON name/value pairs.
Map labels are assigned both an integer and string value. CBOR
encoded tokens MUST use only integer labels. JSON encoded tokens
MUST use only string labels.
TODO: add paragraph here about use for Attestation Evidence and for TODO: add paragraph here about use for Attestation Evidence and for
Results. Results.
3.1. Token ID Claim (cti and jti) 3.1. Token ID Claim (cti and jti)
CWT defines the "cti" claim. JWT defines the "jti" claim. These are CWT defines the "cti" claim. JWT defines the "jti" claim. These are
equivalent to each other in EAT and carry a unique token identifier equivalent to each other in EAT and carry a unique token identifier
as they do in JWT and CWT. They may be used to defend against re use as they do in JWT and CWT. They may be used to defend against re use
of the token but are distinct from the nonce that is used by the of the token but are distinct from the nonce that is used by the
relying party to guarantee freshness and defend against replay. relying party to guarantee freshness and defend against replay.
skipping to change at page 12, line 5 skipping to change at page 13, line 10
systems, as tokens are intended to be embedded in many different systems, as tokens are intended to be embedded in many different
protocols and systems. No two products anywhere, even in completely protocols and systems. No two products anywhere, even in completely
different industries made by two different manufacturers in two different industries made by two different manufacturers in two
different countries should have the same UEID (if they are not global different countries should have the same UEID (if they are not global
and universal in this way, then relying parties receiving them will and universal in this way, then relying parties receiving them will
have to track other characteristics of the device to keep devices have to track other characteristics of the device to keep devices
distinct between manufacturers). distinct between manufacturers).
There are privacy considerations for UEID's. See Section 8.1. There are privacy considerations for UEID's. See Section 8.1.
The UEID should be permanent. It should never change for a given The UEID is permanent. It never change for a given device / entity.
device / entity. In addition, it should not be reprogrammable.
UEID's are variable length. All implementations MUST be able to UEIDs are variable length. All implementations MUST be able to
receive UEID's that are 33 bytes long (1 type byte and 256 bits). receive UEIDs that are 33 bytes long (1 type byte and 256 bits). The
The recommended maximum sent is also 33 bytes. recommended maximum sent is also 33 bytes.
When the entity constructs the UEID, the first byte is a type and the When the entity constructs the UEID, the first byte is a type and the
following bytes the ID for that type. Several types are allowed to following bytes the ID for that type. Several types are allowed to
accommodate different industries and different manufacturing accommodate different industries and different manufacturing
processes and to give options to avoid paying fees for certain types processes and to give options to avoid paying fees for certain types
of manufacturer registrations. of manufacturer registrations.
Creation of new types requires a Standards Action [RFC8126]. Creation of new types requires a Standards Action [RFC8126].
+------+------+-----------------------------------------------------+ +------+------+-----------------------------------------------------+
skipping to change at page 13, line 35 skipping to change at page 15, line 23
that UEIDs be universally unique. that UEIDs be universally unique.
3.4.1. ueid CDDL 3.4.1. ueid CDDL
ueid-type = bstr .size (7..33) ueid-type = bstr .size (7..33)
ueid-claim = ( ueid-claim = (
ueid => ueid-type ueid => ueid-type
) )
3.5. Origination Claim (origination) 3.5. Semi-permanent UEIDs (SUEIDs)
TODO: this claim is likely to be dropped in favor of Endorsement
identifier and locators.
This claim describes the parts of the device or entity that are
creating the EAT. Often it will be tied back to the device or chip
manufacturer. The following table gives some examples:
+-------------------+-----------------------------------------------+ An SEUID is of the same format as a UEID, but it may change to a
| Name | Description | different value on device life-cycle events. Examples of these
+-------------------+-----------------------------------------------+ events are change of ownership, factory reset and on-boarding into an
| Acme-TEE | The EATs are generated in the TEE authored | IoT device management system. A device may have both a UEID and
| | and configured by "Acme" | SUEIDs, neither, one or the other.
| Acme-TPM | The EATs are generated in a TPM manufactured |
| | by "Acme" |
| Acme-Linux-Kernel | The EATs are generated in a Linux kernel |
| | configured and shipped by "Acme" |
| Acme-TA | The EATs are generated in a Trusted |
| | Application (TA) authored by "Acme" |
+-------------------+-----------------------------------------------+
TODO: consider a more structure approach where the name and the URI There may be multiple SUEIDs. Each one has a text string label the
and other are in separate fields. purpose of which is to distinguish it from others in the token. The
label may name the purpose, application or type of the SUEID.
Typically, there will be few SUEDs so there is no need for a formal
labeling mechanism like a registry. The EAT profile may describe how
SUEIDs should be labeled. If there is only one SUEID, the claim
remains a map and there still must be a label. For example, the
label for the SUEID used by FIDO Onboarding Protocol could simply be
"FDO".
TODO: This needs refinement. It is somewhat parallel to issuer claim There are privacy considerations for SUEID's. See Section 8.1.
in CWT in that it describes the authority that created the token.
3.5.1. origination CDDL sueids-type = {
+ tstr => ueid-type
}
origination-claim = ( sueids-claim = (
origination => string-or-uri sueids => sueids-type
) )
3.6. OEM Identification by IEEE (oemid) 3.6. OEM Identification by IEEE (oemid)
The IEEE operates a global registry for MAC addresses and company The IEEE operates a global registry for MAC addresses and company
IDs. This claim uses that database to identify OEMs. The contents IDs. This claim uses that database to identify OEMs. The contents
of the claim may be either an IEEE MA-L, MA-M, MA-S or an IEEE CID of the claim may be either an IEEE MA-L, MA-M, MA-S or an IEEE CID
[IEEE.RA]. An MA-L, formerly known as an OUI, is a 24-bit value used [IEEE.RA]. An MA-L, formerly known as an OUI, is a 24-bit value used
as the first half of a MAC address. MA-M similarly is a 28-bit value as the first half of a MAC address. MA-M similarly is a 28-bit value
uses as the first part of a MAC address, and MA-S, formerly known as uses as the first part of a MAC address, and MA-S, formerly known as
skipping to change at page 15, line 22 skipping to change at page 16, line 46
The hardware version can be claimed at three different levels, the The hardware version can be claimed at three different levels, the
chip, the circuit board and the final device assembly. An EAT can chip, the circuit board and the final device assembly. An EAT can
include any combination these claims. include any combination these claims.
The hardware version is a simple text string the format of which is The hardware version is a simple text string the format of which is
set by each manufacturer. The structure and sorting order of this set by each manufacturer. The structure and sorting order of this
text string can be specified using the version-scheme item from text string can be specified using the version-scheme item from
CoSWID [CoSWID]. CoSWID [CoSWID].
The hardware version can also be given by a 13-digit European Article The hardware version can also be given by a 13-digit [EAN-13]. A new
Number [EAN-13]. An EAN-13 is also known as an International Article CoSWID version scheme is registered with IANA by this document in
Number or most commonly as a bar code. This claim is the ASCII text Section 7.3.3. An EAN-13 is also known as an International Article
representation of actual digits often printed with a bar code. Use Number or most commonly as a bar code.
of this claim must comply with the EAN allocation and assignment
rules. For example, this requires the manufacturer to obtain a
manufacture code from GS1.
Both the simple version string and EAN-13 versions may be included
for the same hardware.
chip-version-claim = ( chip-version-claim = (
chip-version => tstr chip-version => tstr
) )
chip-version-scheme-claim = ( chip-version-scheme-claim = (
chip-version-scheme => $version-scheme chip-version-scheme => $version-scheme
) )
board-version-claim = ( board-version-claim = (
skipping to change at page 16, line 4 skipping to change at page 17, line 24
board-version => tstr board-version => tstr
) )
board-version-scheme-claim = ( board-version-scheme-claim = (
board-version-scheme => $version-scheme board-version-scheme => $version-scheme
) )
device-version-claim = ( device-version-claim = (
device-version => tstr device-version => tstr
) )
device-version-scheme-claim = ( device-version-scheme-claim = (
device-version-scheme => $version-scheme device-version-scheme => $version-scheme
) )
ean-type = text .regexp "[0-9]{13}"
ean-chip-version-claim = (
ean-chip-version => ean-type
)
ean-board-version-claim = (
ean-board-version => ean-type
)
ean-device-version-claim = (
ean-device-version => ean-type
)
hardware-version-claims = ( hardware-version-claims = (
? chip-version-claim, ? chip-version-claim,
? board-version-claim, ? board-version-claim,
? device-version-claim, ? device-version-claim,
? chip-version-scheme-claim, ? chip-version-scheme-claim,
? board-version-scheme-claim, ? board-version-scheme-claim,
? device-version-scheme-claim, ? device-version-scheme-claim,
? ean-chip-version-claim,
? ean-board-version-claim,
? ean-device-version-claim,
) )
3.8. Software Description and Version 3.8. Software Description and Version
TODO: Add claims that reference CoSWID. TODO: Add claims that reference CoSWID.
3.9. The Security Level Claim (security-level) 3.9. The Security Level Claim (security-level)
This claim characterizes the device/entity ability to defend against This claim characterizes the device/entity ability to defend against
attacks aimed at capturing the signing key, forging claims and at attacks aimed at capturing the signing key, forging claims and at
skipping to change at page 17, line 42 skipping to change at page 19, line 4
can define its own proprietary claim. It may consider including both can define its own proprietary claim. It may consider including both
this claim as a coarse indication of security and its own proprietary this claim as a coarse indication of security and its own proprietary
claim as a refined indication. claim as a refined indication.
This claim is not intended as a replacement for a proper end-device This claim is not intended as a replacement for a proper end-device
security certification schemes such as those based on FIPS 140 security certification schemes such as those based on FIPS 140
[FIPS-140] or those based on Common Criteria [Common.Criteria]. The [FIPS-140] or those based on Common Criteria [Common.Criteria]. The
claim made here is solely a self-claim made by the Entity Originator. claim made here is solely a self-claim made by the Entity Originator.
3.9.1. security-level CDDL 3.9.1. security-level CDDL
security-level-cbor-type = &(
unrestricted: 1,
restricted: 2,
secure-restricted: 3,
hardware: 4
)
security-level-type = &( security-level-json-type =
unrestricted: 1, "unrestricted" /
restricted: 2, "restricted" /
secure-restricted: 3, "secure-restricted" /
hardware: 4 "hardware"
)
security-level-claim = ( security-level-claim = (
security-level => security-level-type security-level => security-level-cbor-type / security-level-json-type
) )
3.10. Secure Boot Claim (secure-boot) 3.10. Secure Boot Claim (secure-boot)
The value of true indicates secure boot is enabled. Secure boot is The value of true indicates secure boot is enabled. Secure boot is
considered enabled when base software, the firmware and operating considered enabled when base software, the firmware and operating
system, are under control of the entity manufacturer identified in system, are under control of the entity manufacturer identified in
the oemid claimd described in Section 3.6. This may because the the oemid claimd described in Section 3.6. This may because the
software is in ROM or because it is cryptographically authenticated software is in ROM or because it is cryptographically authenticated
or some combination of the two or other. or some combination of the two or other.
skipping to change at page 20, line 12 skipping to change at page 21, line 32
also indicates that all debug facilities are currently disabled and also indicates that all debug facilities are currently disabled and
have been so since boot/start. have been so since boot/start.
3.11.5. Disabled Fully and Permanently 3.11.5. Disabled Fully and Permanently
This level indicates that all debug capabilities for the target This level indicates that all debug capabilities for the target
device/sub-module are permanently disabled. device/sub-module are permanently disabled.
3.11.6. debug-status CDDL 3.11.6. debug-status CDDL
debug-status-type = &( debug-status-cbor-type = &(
enabled: 0, enabled: 0,
disabled: 1, disabled: 1,
disabled-since-boot: 2, disabled-since-boot: 2,
disabled-permanently: 3, disabled-permanently: 3,
disabled-fully-and-permanently: 4 disabled-fully-and-permanently: 4
) )
debug-status-json-type =
"enabled" /
"disabled" /
"disabled-since-boot" /
"disabled-permanently" /
"disabled-fully-and-permanently"
debug-status-claim = ( debug-status-claim = (
debug-status => debug-status-type debug-status => debug-status-cbor-type / debug-status-json-type
) )
3.12. Including Keys 3.12. Including Keys
An EAT may include a cryptographic key such as a public key. The An EAT may include a cryptographic key such as a public key. The
signing of the EAT binds the key to all the other claims in the signing of the EAT binds the key to all the other claims in the
token. token.
The purpose for inclusion of the key may vary by use case. For The purpose for inclusion of the key may vary by use case. For
example, the key may be included as part of an IoT device onboarding example, the key may be included as part of an IoT device onboarding
skipping to change at page 22, line 16 skipping to change at page 23, line 39
longitude => number, longitude => number,
? altitude => number, ? altitude => number,
? accuracy => number, ? accuracy => number,
? altitude-accuracy => number, ? altitude-accuracy => number,
? heading => number, ? heading => number,
? speed => number, ? speed => number,
? timestamp => ~time-int, ? timestamp => ~time-int,
? age => uint ? age => uint
} }
latitude = 1 latitude = 1 / "latitude"
longitude = 2 longitude = 2 / "longitude"
altitude = 3 altitude = 3 / "altitude"
accuracy = 4 accuracy = 4 / "accuracy"
altitude-accuracy = 5 altitude-accuracy = 5 / "altitude-accuracy"
heading = 6 heading = 6 / "heading"
speed = 7 speed = 7 / "speed"
timestamp = 8 timestamp = 8 / "timestamp"
age = 9 age = 9 / "age"
location-claim = ( location-claim = (
location => location-type location-label => location-type
) )
3.14. The Uptime Claim (uptime) 3.14. The Uptime Claim (uptime)
The "uptime" claim contains a value that represents the number of The "uptime" claim contains a value that represents the number of
seconds that have elapsed since the entity or submod was last booted. seconds that have elapsed since the entity or submod was last booted.
3.14.1. uptime CDDL 3.14.1. uptime CDDL
uptime-claim = ( uptime-claim = (
uptime => uint uptime => uint
) )
3.14.2. The Boot Seed Claim (boot-seed) 3.15. The Boot Seed Claim (boot-seed)
The Boot Seed claim is a random value created at system boot time The Boot Seed claim is a random value created at system boot time
that will allow differentiation of reports from different boot that will allow differentiation of reports from different boot
sessions. This value is usually public and not protected. It is not sessions. This value is usually public and not protected. It is not
the same as a seed for a random number generator which must be kept the same as a seed for a random number generator which must be kept
secret. secret.
boot-seed-claim = ( boot-seed-claim = (
boot-seed => bytes boot-seed => bytes
) )
3.15. The Intended Use Claim (intended-use) 3.16. The Intended Use Claim (intended-use)
EAT's may be used in the context of several different applications. EAT's may be used in the context of several different applications.
The intended-use claim provides an indication to an EAT consumer The intended-use claim provides an indication to an EAT consumer
about the intended usage of the token. This claim can be used as a about the intended usage of the token. This claim can be used as a
way for an application using EAT to internally distinguish between way for an application using EAT to internally distinguish between
different ways it uses EAT. different ways it uses EAT.
1 - Generic Generic attestation describes an application where the 1 - Generic Generic attestation describes an application where the
EAT consumer requres the most up-to-date security assessment of EAT consumer requres the most up-to-date security assessment of
the attesting entity. It is expected that this is the most the attesting entity. It is expected that this is the most
skipping to change at page 23, line 41 skipping to change at page 25, line 15
may be used as part of the certificate signing request (CSR). may be used as part of the certificate signing request (CSR).
5 - Proof-of-Possession An EAT consumer may require an attestation 5 - Proof-of-Possession An EAT consumer may require an attestation
as part of an accompanying proof-of-possession (PoP) appication. as part of an accompanying proof-of-possession (PoP) appication.
More precisely, a PoP transaction is intended to provide to the More precisely, a PoP transaction is intended to provide to the
recipient cryptographically-verifiable proof that the sender has recipient cryptographically-verifiable proof that the sender has
posession of a key. This kind of attestation may be neceesary to posession of a key. This kind of attestation may be neceesary to
verify the security state of the entity storing the private key verify the security state of the entity storing the private key
used in a PoP application. used in a PoP application.
3.15.1. intended-use CDDL 3.16.1. intended-use CDDL
intended-use-type = &(
intended-use-cbor-type = &(
generic: 1, generic: 1,
registration: 2, registration: 2,
provisioning: 3, provisioning: 3,
csr: 4, csr: 4,
pop: 5 pop: 5
) )
intended-use-json-type =
"generic" /
"registration" /
"provisioning" /
"csr" /
"pop"
intended-use-claim = ( intended-use-claim = (
intended-use => intended-use-type intended-use => intended-use-cbor-type / intended-use-json-type
) )
3.16. The Profile Claim (profile) 3.17. The Profile Claim (profile)
See Section 5 for the detailed description of a profile. See Section 5 for the detailed description of a profile.
A profile is identified by either a URL or an OID. Typically, the A profile is identified by either a URL or an OID. Typically, the
URI will reference a document describing the profile. An OID is just URI will reference a document describing the profile. An OID is just
a unique identifier for the profile. It may exist anywhere in the a unique identifier for the profile. It may exist anywhere in the
OID tree. There is no requirement that the named document be OID tree. There is no requirement that the named document be
publicly accessible. The primary purpose of the profile claim is to publicly accessible. The primary purpose of the profile claim is to
uniquely identify the profile even if it is a private profile. uniquely identify the profile even if it is a private profile.
The OID is encoded in CBOR according to [CBOR-OID] and the URI The OID is encoded in CBOR according to [CBOR-OID] and the URI
according to [RFC8949]. Both are unwrapped and thus not tags. The according to [RFC8949]. Both are unwrapped and thus not tags. The
OID is always absolute and never relative. If the claims CBOR type OID is always absolute and never relative. If the claims CBOR type
is a text string it is a URI and if a byte string it is an OID. is a text string it is a URI and if a byte string it is an OID.
Note that this named "eat_profile" for JWT and is distinct from the Note that this named "eat_profile" for JWT and is distinct from the
already registered "profile" claim in the JWT claims registry. already registered "profile" claim in the JWT claims registry.
profile-claim = ( oid = #6.4000(bstr) ; TODO: fill this in with correct CDDL from OID RFC
profile => ~uri / ~oid
profile-claim = (
profile => ~uri / ~oid
)
3.18. The Software Manifests Claim (manifests)
This claim contains descriptions of software that is present on the
device. These manifests are installed on the device when the
software is installed or are created as part of the installation
process. Installation is anything that adds software to the device,
possibly factory installation, the user installing elective
applications and so on. The defining characteristic is that they are
created by the software manufacturer. The purpose of these claims in
an EAT is to relay them without modification to the Verifier and/or
the Relying Party.
In some cases these will be signed by the software manufacturer
independent of any signing for the purpose of EAT attestation.
Manifest claims should include the manufacturer's signature (which
will be signed over by the attestation signature). In other cases
the attestation signature will be the only one.
This claim allows multiple formats for the manifest. For example the
manifest may be a CBOR-format CoSWID, an XML-format SWID or other.
Identification of the type of manifest is always by a CBOR tag. In
many cases, for examples CoSWID, a tag will already be registered
with IANA. If not, a tag MUST be registered. It can be in the
first-come-first-served space which has minimal requirements for
registration.
The claim is an array of one or more manifests. To facilitate hand
off of the manifest to a decoding library, each manifest is contained
in a byte string. This occurs for CBOR-format manifests as well as
non-CBOR format manifests.
If a particular manifest type uses CBOR encoding, then the item in
the array for it MUST be a byte string that contains a CBOR tag. The
EAT decoder must decode the byte string and then the CBOR within it
to find the tag number to identify the type of manifest. The
contents of the byte string is then handed to the particular manifest
processor for that type of manifest. CoSWID and SUIT manifest are
examples of this.
If a particular manifest type does not use CBOR encoding, then the
item in the array for it must be a CBOR tag that contains a byte
string. The EAT decoder uses the tag to identify the processor for
that type of manifest. The contents of the tag, the byte string, are
handed to the manifest processor. Note that a byte string is used to
contain the manifest whether it is a text based format or not. An
example of this is an XML format ISO/IEC 19770 SWID.
It is not possible to describe the above requirements in CDDL so the
type for an individual manifest is any in the CDDL below. The above
text sets the encoding requirement.
This claim allows for multiple manifests in one token since multiple
software packages are likely to be present. The multiple manifests
may be of multiple formats. In some cases EAT submodules may be used
instead of the array structure in this claim for multiple manifests.
When the [CoSWID] format is used, it MUST be a payload CoSWID, not an
evidence CoSWID.
manifests-claim = (
manifests => manifests-type
) )
3.17. The Submodules Part of a Token (submods) manifests-type = [+ $manifest-formats]
; Must be a CoSWID payload type
$manifest-formats /= bytes .cbor concise-swid-tag
$manifest-formats /= bytes .cbor SUIT_Envelope_Tagged
3.19. The Software Evidence Claim {swevidence}
This claim contains descriptions, lists, evidence or measurements of
the software that exists on the device. The defining characteristic
of this claim is that its contents are created by processes on the
device that inventory, measure or otherwise characterize the software
on the device. The contents of this claim do not originate from the
software manufacturer.
In most cases the contents of this claim are signed as part of
attestation signing, but independent signing in addition to the
attestation signing is not ruled out when a particular evidence
format supports it.
This claim uses the same mechanism for identification of the type of
the swevidence as is used for the type of the manifest in the
manifests claim. It also uses the same byte string based mechanism
for containing the claim and easing the hand off to a processing
library. See the discussion above in the manifests claim.
When the [CoSWID] format is used, it MUST be evidence CoSWIDs, not
payload CoSWIDS.
swevidence-claim = (
swevidence => swevidence-type
)
swevidence-type = [+ $swevidence-formats]
; Must be a CoSWID evidence type
$swevidence-formats /= bytes .cbor concise-swid-tag
3.20. The Submodules Part of a Token (submods)
Some devices are complex, having many subsystems or submodules. A Some devices are complex, having many subsystems or submodules. A
mobile phone is a good example. It may have several connectivity mobile phone is a good example. It may have several connectivity
submodules for communications (e.g., Wi-Fi and cellular). It may submodules for communications (e.g., Wi-Fi and cellular). It may
have subsystems for low-power audio and video playback. It may have have subsystems for low-power audio and video playback. It may have
one or more security-oriented subsystems like a TEE or a Secure one or more security-oriented subsystems like a TEE or a Secure
Element. Element.
The claims for each these can be grouped together in a submodule. The claims for each these can be grouped together in a submodule.
The submods part of a token are in a single map/object with many The submods part of a token are in a single map/object with many
entries, one per submodule. There is only one submods map in a entries, one per submodule. There is only one submods map in a
token. It is identified by its specific label. It is a peer to token. It is identified by its specific label. It is a peer to
other claims, but it is not called a claim because it is a container other claims, but it is not called a claim because it is a container
for a claim set rather than an individual claim. This submods part for a claim set rather than an individual claim. This submods part
of a token allows what might be called recursion. It allows claim of a token allows what might be called recursion. It allows claim
sets inside of claim sets inside of claims sets... sets inside of claim sets inside of claims sets...
3.17.1. Two Types of Submodules 3.20.1. Two Types of Submodules
Each entry in the submod map is one of two types: Each entry in the submod map is one of two types:
o A non-token submodule that is a map or object directly containing o A non-token submodule that is a map or object directly containing
claims for the submodule. claims for the submodule.
o A nested EAT that is a fully formed, independently signed EAT o A nested EAT that is a fully formed, independently signed EAT
token token
3.17.1.1. Non-token Submodules 3.20.1.1. Non-token Submodules
This is simply a map or object containing claims about the submodule. This is simply a map or object containing claims about the submodule.
It may contain claims that are the same as its surrounding token or It may contain claims that are the same as its surrounding token or
superior submodules. For example, the top-level of the token may superior submodules. For example, the top-level of the token may
have a UEID, a submod may have a different UEID and a further have a UEID, a submod may have a different UEID and a further
subordinate submodule may also have a UEID. subordinate submodule may also have a UEID.
It is signed/encrypted along with the rest of the token and thus the It is signed/encrypted along with the rest of the token and thus the
claims are secured by the same Attester with the same signing key as claims are secured by the same Attester with the same signing key as
the rest of the token. the rest of the token.
If a token is in CBOR format (a CWT or a UCCS), all non-token If a token is in CBOR format (a CWT or a UCCS), all non-token
submodules must be CBOR format. If a token in in JSON format (a submodules must be CBOR format. If a token in in JSON format (a
JWT), all non-token submodules must be in JSON format. JWT), all non-token submodules must be in JSON format.
When decoding, this type of submodule is recognized from the other When decoding, this type of submodule is recognized from the other
type by being a data item of type map for CBOR or type object for type by being a data item of type map for CBOR or type object for
JSON. JSON.
3.17.1.2. Nested EATs 3.20.1.2. Nested EATs
This type of submodule is a fully formed secured EAT as defined in This type of submodule is a fully formed secured EAT as defined in
this document except that it MUST NOT be a UCCS or an unsecured JWT. this document except that it MUST NOT be a UCCS or an unsecured JWT.
A nested token that is one that is always secured using COSE or JOSE, A nested token that is one that is always secured using COSE or JOSE,
usually by an independent Attester. When the surrounding EAT is a usually by an independent Attester. When the surrounding EAT is a
CWT or secured JWT, the nested token becomes securely bound with the CWT or secured JWT, the nested token becomes securely bound with the
other claims in the surrounding token. other claims in the surrounding token.
It is allowed to have a CWT as a submodule in a JWT and vice versa, It is allowed to have a CWT as a submodule in a JWT and vice versa,
but this SHOULD be avoided unless necessary. but this SHOULD be avoided unless necessary.
3.17.1.2.1. Surrounding EAT is CBOR format 3.20.1.2.1. Surrounding EAT is CBOR format
They type of an EAT nested in a CWT is determined by whether the CBOR They type of an EAT nested in a CWT is determined by whether the CBOR
type is a text string or a byte string. If a text string, then it is type is a text string or a byte string. If a text string, then it is
a JWT. If a byte string, then it is a CWT. a JWT. If a byte string, then it is a CWT.
A CWT nested in a CBOR-format token is always wrapped by a byte A CWT nested in a CBOR-format token is always wrapped by a byte
string for easier handling with standard CBOR decoders and token string for easier handling with standard CBOR decoders and token
processing APIs that will typically take a byte buffer as input. processing APIs that will typically take a byte buffer as input.
Nested CWTs may be either a CWT CBOR tag or a CWT Protocol Message. Nested CWTs may be either a CWT CBOR tag or a CWT Protocol Message.
COSE layers in nested CWT EATs MUST be a COSE_Tagged_Message, never a COSE layers in nested CWT EATs MUST be a COSE_Tagged_Message, never a
COSE_Untagged_Message. If a nested EAT has more than one level of COSE_Untagged_Message. If a nested EAT has more than one level of
COSE, for example one that is both encrypted and signed, a COSE, for example one that is both encrypted and signed, a
COSE_Tagged_message must be used at every level. COSE_Tagged_message must be used at every level.
3.17.1.2.2. Surrounding EAT is JSON format 3.20.1.2.2. Surrounding EAT is JSON format
When a CWT is nested in a JWT, it must be as a 55799 tag in order to When a CWT is nested in a JWT, it must be as a 55799 tag in order to
distinguish it from a nested JWT. distinguish it from a nested JWT.
When a nested EAT in a JWT is decoded, first remove the base64url When a nested EAT in a JWT is decoded, first remove the base64url
encoding. Next, check to see if it starts with the bytes 0xd9d9f7. encoding. Next, check to see if it starts with the bytes 0xd9d9f7.
If so, then it is a CWT as a JWT will never start with these four If so, then it is a CWT as a JWT will never start with these four
bytes. If not if it is a JWT. bytes. If not if it is a JWT.
Other than the 55799 tag requirement, tag usage for CWT's nested in a Other than the 55799 tag requirement, tag usage for CWT's nested in a
JSON format token follow the same rules as for CWTs nested in CBOR- JSON format token follow the same rules as for CWTs nested in CBOR-
format tokens. It may be a CWT CBOR tag or a CWT Protocol Message format tokens. It may be a CWT CBOR tag or a CWT Protocol Message
and COSE_Tagged_Message MUST be used at all COSE layers. and COSE_Tagged_Message MUST be used at all COSE layers.
3.17.1.3. Unsecured JWTs and UCCS Tokens as Submodules 3.20.1.3. Unsecured JWTs and UCCS Tokens as Submodules
To incorporate a UCCS token as a submodule, it MUST be as a non-token To incorporate a UCCS token as a submodule, it MUST be as a non-token
submodule. This can be accomplished inserting the content of the submodule. This can be accomplished inserting the content of the
UCCS Tag into the submodule map. The content of a UCCS tag is UCCS Tag into the submodule map. The content of a UCCS tag is
exactly a map of claims as required for a non-token submodule. If exactly a map of claims as required for a non-token submodule. If
the UCCS is not a UCCS tag, then it can just be inserted into the the UCCS is not a UCCS tag, then it can just be inserted into the
submodule map directly. submodule map directly.
The definition of a nested EAT type of submodule is that it is one The definition of a nested EAT type of submodule is that it is one
that is secured (signed) by an Attester. Since UCCS tokens are that is secured (signed) by an Attester. Since UCCS tokens are
skipping to change at page 27, line 11 skipping to change at page 30, line 44
To incorporate an Unsecured JWT as a submodule, the null-security To incorporate an Unsecured JWT as a submodule, the null-security
JOSE wrapping should be removed. The resulting claims set should be JOSE wrapping should be removed. The resulting claims set should be
inserted as a non-token submodule. inserted as a non-token submodule.
To incorporate a UCCS token in a surrounding JSON token, the UCCS To incorporate a UCCS token in a surrounding JSON token, the UCCS
token claims should be translated from CBOR to JSON. To incorporate token claims should be translated from CBOR to JSON. To incorporate
an Unsecured JWT into a surrounding CBOR-format token, the null- an Unsecured JWT into a surrounding CBOR-format token, the null-
security JOSE should be removed and the claims translated from JSON security JOSE should be removed and the claims translated from JSON
to CBOR. to CBOR.
3.17.2. No Inheritance 3.20.2. No Inheritance
The subordinate modules do not inherit anything from the containing The subordinate modules do not inherit anything from the containing
token. The subordinate modules must explicitly include all of their token. The subordinate modules must explicitly include all of their
claims. This is the case even for claims like the nonce and age. claims. This is the case even for claims like the nonce and age.
This rule is in place for simplicity. It avoids complex inheritance This rule is in place for simplicity. It avoids complex inheritance
rules that might vary from one type of claim to another. rules that might vary from one type of claim to another.
3.17.3. Security Levels 3.20.3. Security Levels
The security level of the non-token subordinate modules should always The security level of the non-token subordinate modules should always
be less than or equal to that of the containing modules in the case be less than or equal to that of the containing modules in the case
of non-token submodules. It makes no sense for a module of lesser of non-token submodules. It makes no sense for a module of lesser
security to be signing claims of a module of higher security. An security to be signing claims of a module of higher security. An
example of this is a TEE signing claims made by the non-TEE parts example of this is a TEE signing claims made by the non-TEE parts
(e.g. the high-level OS) of the device. (e.g. the high-level OS) of the device.
The opposite may be true for the nested tokens. They usually have The opposite may be true for the nested tokens. They usually have
their own more secure key material. An example of this is an their own more secure key material. An example of this is an
embedded secure element. embedded secure element.
3.17.4. Submodule Names 3.20.4. Submodule Names
The label or name for each submodule in the submods map is a text The label or name for each submodule in the submods map is a text
string naming the submodule. No submodules may have the same name. string naming the submodule. No submodules may have the same name.
3.17.5. submods CDDL 3.20.5. submods CDDL
; The part of a token that contains all the submodules. It is a peer ; The part of a token that contains all the submodules. It is a peer
; with the claims in the token, but not a claim, only a map/object to ; with the claims in the token, but not a claim, only a map/object to
; hold all the submodules. ; hold all the submodules.
submods-part = ( submods-part = (
submods => submods-type submods => submods-type
) )
submods-type = { + submod-type } submods-type = { + submod-type }
skipping to change at page 28, line 34 skipping to change at page 32, line 34
; format. ; format.
nested-token = bstr / tstr; nested-token = bstr / tstr;
; Each submodule has a unique text string name. ; Each submodule has a unique text string name.
submod-name = tstr submod-name = tstr
4. Endorsements and Verification Keys 4. Endorsements and Verification Keys
TODO: fill this section in. It will discuss key IDs, endorsement ID The Verifier must possess the correct key when it performs the
and such that are needed as input needed to by the Verifier to verify cryptographic part of an EAT verification (e.g., verifying the COSE
the signature. This will NOT discuss the contents of an Endorsement, signature). This section describes several ways to identify the
just and ID/locator. verification key. There is not one standard method.
The verification key itself may be a public key, a symmetric key or
something complicated in the case of a scheme like Direct Anonymous
Attestation (DAA).
RATS Architecture [RATS.Architecture] describes what is called an
Endorsement. This is an input to the Verifier that is usually the
basis of the trust placed in an EAT and the Attester that generated
it. It may contain the public key for verification of the signature
on the EAT. It may contain Reference Values to which EAT claims are
compared as part of the verification process. It may contain implied
claims, those that are passed on to the Relying Party in Attestation
Results.
There is not yet any standard format(s) for an Endorsement. One
format that may be used for an Endorsement is an X.509 certificate.
Endorsement data like Reference Values and implied claims can be
carried in X.509 v3 extensions. In this use, the public key in the
X.509 certificate becomes the verification key, so identification of
the Endorsement is also identification of the verification key.
The verification key identification and establishment of trust in the
EAT and the attester may also be by some other means than an
Endorsement.
For the components (Attester, Verifier, Relying Party,...) of a
particular end-end attestation system to reliably interoperate, its
definition should specify how the verification key is identified.
Usually, this will be in the profile document for a particular
attestation system.
4.1. Identification Methods
Following is a list of possible methods of key identification. A
specific attestation system may employ any one of these or one not
listed here.
The following assumes Endorsements are X.509 certificates or
equivalent and thus does not mention or define any identifier for
Endorsements in other formats. If such an Endorsement format is
created, new identifiers for them will also need to be created.
4.1.1. COSE/JWS Key ID
The COSE standard header parameter for Key ID (kid) may be used. See
[RFC8152] and [RFC7515]
COSE leaves the semantics of the key ID open-ended. It could be a
record locator in a database, a hash of a public key, an input to a
KDF, an authority key identifier (AKI) for an X.509 certificate or
other. The profile document should specify what the key ID's
semantics are.
4.1.2. JWS and COSE X.509 Header Parameters
COSE X.509 [COSE.X509.Draft] and JSON Web Siganture [RFC7515] define
several header parameters (x5t, x5u,...) for referencing or carrying
X.509 certificates any of which may be used.
The X.509 certificate may be an Endorsement and thus carrying
additional input to the Verifier. It may be just an X.509
certificate, not an Endorsement. The same header parameters are used
in both cases. It is up to the attestation system design and the
Verifier to determine which.
4.1.3. CBOR Certificate COSE Header Parameters
Compressed X.509 and CBOR Native certificates are defined by CBOR
Certificates [CBOR.Cert.Draft]. These are semantically compatible
with X.509 and therefore can be used as an equivalent to X.509 as
described above.
These are identified by their own header parameters (c5t, c5u,...).
4.1.4. Claim-Based Key Identification
For some attestation systems, a claim may be re-used as a key
identifier. For example, the UEID uniquely identifies the device and
therefore can work well as a key identifier or Endorsement
identifier.
This has the advantage that key identification requires no additional
bytes in the EAT and makes the EAT smaller.
This has the disadvantage that the unverified EAT must be
substantially decoded to obtain the identifier since the identifier
is in the COSE/JOSE payload, not in the headers.
4.2. Other Considerations
In all cases there must be some way that the verification key is
itself verified or determined to be trustworthy. The key
identification itself is never enough. This will always be by some
out-of-band mechanism that is not described here. For example, the
Verifier may be configured with a root certificate or a master key by
the Verifier system administrator.
Often an X.509 certificate or an Endorsement carries more than just
the verification key. For example, an X.509 certificate might have
key usage constraints and an Endorsement might have Reference Values.
When this is the case, the key identifier must be either a protected
header or in the payload such that it is cryptographically bound to
the EAT. This is in line with the requirements in section 6 on Key
Identification in JSON Web Signature [RFC7515].
5. Profiles 5. Profiles
This EAT specification does not gaurantee that implementations of it This EAT specification does not gaurantee that implementations of it
will interoperate. The variability in this specification is will interoperate. The variability in this specification is
necessary to accommodate the widely varying use cases. An EAT necessary to accommodate the widely varying use cases. An EAT
profile narrows the specification for a specific use case. An ideal profile narrows the specification for a specific use case. An ideal
EAT profile will gauarantee interoperability. EAT profile will gauarantee interoperability.
The profile can be named in the token using the profile claim The profile can be named in the token using the profile claim
described in Section 3.16. described in Section 3.17.
5.1. List of Profile Issues 5.1. Format of a Profile Document
A profile document doesn't have to be in any particular format. It
may be simple text, something more formal or a combination.
In some cases CDDL may be created that replaces CDDL in this or other
document to express some profile requirements. For example, to
require the altitude data item in the location claim, CDDL can be
written that replicates the location claim with the altitude no
longer optional.
5.2. List of Profile Issues
The following is a list of EAT, CWT, UCCS, JWS, COSE, JOSE and CBOR The following is a list of EAT, CWT, UCCS, JWS, COSE, JOSE and CBOR
options that a profile should address. options that a profile should address.
5.1.1. Use of JSON, CBOR or both 5.2.1. Use of JSON, CBOR or both
The profile should indicate whether the token format should be CBOR, The profile should indicate whether the token format should be CBOR,
JSON, both or even some other encoding. If some other encoding, a JSON, both or even some other encoding. If some other encoding, a
specification for how the CDDL described here is serialized in that specification for how the CDDL described here is serialized in that
encoding is necessary. encoding is necessary.
This should be addressed for the top-level token and for any nested This should be addressed for the top-level token and for any nested
tokens. For example, a profile might require all nested tokens to be tokens. For example, a profile might require all nested tokens to be
of the same encoding of the top level token. of the same encoding of the top level token.
5.1.2. CBOR Map and Array Encoding 5.2.2. CBOR Map and Array Encoding
The profile should indicate whether definite-length arrays/maps, The profile should indicate whether definite-length arrays/maps,
indefinite-length arrays/maps or both are allowed. A good default is indefinite-length arrays/maps or both are allowed. A good default is
to allow only definite-length arrays/maps. to allow only definite-length arrays/maps.
An alternate is to allow both definite and indefinite-length arrays/ An alternate is to allow both definite and indefinite-length arrays/
maps. The decoder should accept either. Encoders that need to fit maps. The decoder should accept either. Encoders that need to fit
on very small hardware or be actually implement in hardware can use on very small hardware or be actually implement in hardware can use
indefinite-length encoding. indefinite-length encoding.
This applies to individual EAT claims, CWT and COSE parts of the This applies to individual EAT claims, CWT and COSE parts of the
implementation. implementation.
5.1.3. CBOR String Encoding 5.2.3. CBOR String Encoding
The profile should indicate whether definite-length strings, The profile should indicate whether definite-length strings,
indefinite-length strings or both are allowed. A good default is to indefinite-length strings or both are allowed. A good default is to
allow only definite-length strings. As with map and array encoding, allow only definite-length strings. As with map and array encoding,
allowing indefinite-length strings can be beneficial for some smaller allowing indefinite-length strings can be beneficial for some smaller
implementations. implementations.
5.1.4. COSE/JOSE Protection 5.2.4. CBOR Preferred Serialization
The profile should indicate whether encoders must use preferred
serialization. The profile should indicate whether decoders must
accept non-preferred serialization.
5.2.5. COSE/JOSE Protection
COSE and JOSE have several options for signed, MACed and encrypted COSE and JOSE have several options for signed, MACed and encrypted
messages. EAT/CWT has the option to have no protection using UCCS messages. EAT/CWT has the option to have no protection using UCCS
and JOSE has a NULL protection option. It is possible to implement and JOSE has a NULL protection option. It is possible to implement
no protection, sign only, MAC only, sign then encrypt and so on. All no protection, sign only, MAC only, sign then encrypt and so on. All
combinations allowed by COSE, JOSE, JWT, CWT and UCCS are allowed by combinations allowed by COSE, JOSE, JWT, CWT and UCCS are allowed by
EAT. EAT.
The profile should list the protections that must be supported by all The profile should list the protections that must be supported by all
decoders implementing the profile. The encoders them must implement decoders implementing the profile. The encoders them must implement
a subset of what is listed for the decoders, perhaps only one. a subset of what is listed for the decoders, perhaps only one.
Implementations may choose to sign or MAC before encryption so that Implementations may choose to sign or MAC before encryption so that
the implementation layer doing the signing or MACing can be the the implementation layer doing the signing or MACing can be the
smallest. It is often easier to make smaller implementations more smallest. It is often easier to make smaller implementations more
secure, perhaps even implementing in solely in hardware. The key secure, perhaps even implementing in solely in hardware. The key
material for a signature or MAC is a private key, while for material for a signature or MAC is a private key, while for
encryption it is likely to be a public key. The key for encryption encryption it is likely to be a public key. The key for encryption
requires less protection. requires less protection.
5.1.5. COSE/JOSE Algorithms 5.2.6. COSE/JOSE Algorithms
The profile document should list the COSE algorithms that a Verifier The profile document should list the COSE algorithms that a Verifier
must implement. The Attester will select one of them. Since there must implement. The Attester will select one of them. Since there
is no negotiation, the Verifier should implement all algorithms is no negotiation, the Verifier should implement all algorithms
listed in the profile. listed in the profile.
5.1.6. Verification Key Identification 5.2.7. Verification Key Identification
Section Section 4 describes a number of methods for identifying a Section Section 4 describes a number of methods for identifying a
verification key. The profile document should specify one of these verification key. The profile document should specify one of these
or one that is not described. The ones described in this document or one that is not described. The ones described in this document
are only roughly described. The profile document should go into the are only roughly described. The profile document should go into the
full detail. full detail.
5.1.7. Endorsement Identification 5.2.8. Endorsement Identification
Similar to, or perhaps the same as Verification Key Identification, Similar to, or perhaps the same as Verification Key Identification,
the profile may wish to specify how Endorsements are to be the profile may wish to specify how Endorsements are to be
identified. However note that Endorsement Identification is identified. However note that Endorsement Identification is
optional, where as key identification is not. optional, where as key identification is not.
5.1.8. Required Claims 5.2.9. Freshness
Just about every use case will require some means of knowing the EAT
is recent enough and not a replay of an old token. The profile
should describe how freshness is achieved. The section on Freshness
in [RATS-Architecture] describes some of the possible solutions to
achieve this.
5.2.10. Required Claims
The profile can list claims whose absence results in Verification The profile can list claims whose absence results in Verification
failure. failure.
5.1.9. Prohibited Claims 5.2.11. Prohibited Claims
The profile can list claims whose presence results in Verification The profile can list claims whose presence results in Verification
failure. failure.
5.1.10. Additional Claims 5.2.12. Additional Claims
The profile may describe entirely new claims. These claims can be The profile may describe entirely new claims. These claims can be
required or optional. required or optional.
5.1.11. Refined Claim Definition 5.2.13. Refined Claim Definition
The profile may lock down optional aspects of individual claims. For The profile may lock down optional aspects of individual claims. For
example, it may require altitude in the location claim, or it may example, it may require altitude in the location claim, or it may
require that HW Versions always be described using EAN-13. require that HW Versions always be described using EAN-13.
5.1.12. CBOR Tags 5.2.14. CBOR Tags
The profile should specify whether the token should be a CWT Tag or The profile should specify whether the token should be a CWT Tag or
not. Similarly, the profile should specify whether the token should not. Similarly, the profile should specify whether the token should
be a UCCS tag or not. be a UCCS tag or not.
When COSE protection is used, the profile should specify whether COSE When COSE protection is used, the profile should specify whether COSE
tags are used or not. Note that RFC 8392 requires COSE tags be used tags are used or not. Note that RFC 8392 requires COSE tags be used
in a CWT tag. in a CWT tag.
Often a tag is unncessary because the surrounding or carrying Often a tag is unncessary because the surrounding or carrying
protocol identifies the object as an EAT. protocol identifies the object as an EAT.
5.2.15. Manifests and Software Evidence Claims
The profile should specify which formats are allowed for the
manifests and software evidence claims. The profile may also go on
to say which parts and options of these formats are used, allowed and
prohibited.
6. Encoding 6. Encoding
This makes use of the types defined in CDDL Appendix D, Standard This makes use of the types defined in CDDL Appendix D, Standard
Prelude. Prelude.
Some of the CDDL included here is for claims that are defined in CWT Some of the CDDL included here is for claims that are defined in CWT
[RFC8392] or JWT [RFC7519] or are in the IANA CWT or JWT registries. [RFC8392] or JWT [RFC7519] or are in the IANA CWT or JWT registries.
CDDL was not in use when these claims where defined. CDDL was not in use when these claims where defined.
6.1. Common CDDL Types 6.1. Common CDDL Types
time-int is identical to the epoch-based time, but disallows time-int is identical to the epoch-based time, but disallows
floating-point representation. floating-point representation.
Note that unless expliclity indicated, URIs are not the URI tag
defined in [RFC8949]. They are just text strings that contain a URI.
string-or-uri = tstr string-or-uri = tstr
time-int = #6.1(int) time-int = #6.1(int)
6.2. CDDL for CWT-defined Claims 6.2. CDDL for CWT-defined Claims
This section provides CDDL for the claims defined in CWT. It is non- This section provides CDDL for the claims defined in CWT. It is non-
normative as [RFC8392] is the authoritative definition of these normative as [RFC8392] is the authoritative definition of these
claims. claims.
Note that the subject, issue and audience claims may be a text string
containing a URI per [RFC8392] and [RFC7519]. These are never the
URI tag defined in [RFC8949].
$$eat-extension //= ( $$eat-extension //= (
? issuer => text, ? issuer => text,
? subject => text, ? subject => text,
? audience => text, ? audience => text,
? expiration => time, ? expiration => time,
? not-before => time, ? not-before => time,
? issued-at => time, ? issued-at => time,
? cwt-id => bytes, ? cwt-id => bytes,
) )
skipping to change at page 32, line 26 skipping to change at page 40, line 4
subject = 2 subject = 2
audience = 3 audience = 3
expiration = 4 expiration = 4
not-before = 5 not-before = 5
issued-at = 6 issued-at = 6
cwt-id = 7 cwt-id = 7
6.3. JSON 6.3. JSON
6.3.1. JSON Labels 6.3.1. JSON Labels
; The following are Claim Keys (labels) assigned for JSON-encoded tokens. ; The following are Claim Keys (labels) assigned for JSON-encoded tokens.
ueid /= "ueid" ueid /= "ueid"
sueids /= "sueids"
nonce /= "nonce" nonce /= "nonce"
origination /= "origination"
oemid /= "oemid" oemid /= "oemid"
security-level /= "seclevel" security-level /= "seclevel"
secure-boot /= "secboot" secure-boot /= "secboot"
debug-status /= "dbgstat" debug-status /= "dbgstat"
location /= "location" location /= "location"
uptime /= "uptime" uptime /= "uptime"
profile /= "eat-profile" profile /= "eat-profile"
intended-use /= "intuse" intended-use /= "intuse"
boot-seed /= "bootseed" boot-seed /= "bootseed"
submods /= "submods" submods /= "submods"
timestamp /= "timestamp" timestamp /= "timestamp"
manifests /= "manifests"
swevidence /= "swevidence"
latitude /= "lat" latitude /= "lat"
longitude /= "long" longitude /= "long"
altitude /= "alt" altitude /= "alt"
accuracy /= "accry" accuracy /= "accry"
altitude-accuracy /= "alt-accry" altitude-accuracy /= "alt-accry"
heading /= "heading" heading /= "heading"
speed /= "speed" speed /= "speed"
6.3.2. JSON Interoperability 6.3.2. JSON Interoperability
JSON should be encoded per RFC 8610 Appendix E. In addition, the JSON should be encoded per RFC 8610 Appendix E. In addition, the
following CDDL types are encoded in JSON as follows: following CDDL types are encoded in JSON as follows:
o bstr - must be base64url encoded o bstr - must be base64url encoded
o time - must be encoded as NumericDate as described section 2 of o time - must be encoded as NumericDate as described section 2 of
[RFC7519]. [RFC7519].
skipping to change at page 34, line 31 skipping to change at page 42, line 13
or invalid UTF-8 strings. or invalid UTF-8 strings.
6.5. Collected CDDL 6.5. Collected CDDL
; This is the top-level definition of the claims in EAT tokens. To ; This is the top-level definition of the claims in EAT tokens. To
; form an actual EAT Token, this claim set is enclosed in a COSE, JOSE ; form an actual EAT Token, this claim set is enclosed in a COSE, JOSE
; or UCCS message. ; or UCCS message.
eat-claim-set = { eat-claim-set = {
? ueid-claim, ? ueid-claim,
? sueids-claim,
? nonce-claim, ? nonce-claim,
? origination-claim,
? oemid-claim, ? oemid-claim,
? hardware-version-claims, ? hardware-version-claims,
? security-level-claim, ? security-level-claim,
? secure-boot-claim, ? secure-boot-claim,
? debug-status-claim, ? debug-status-claim,
? location-claim, ? location-claim,
? intended-use-claim,
? profile-claim,
? uptime-claim, ? uptime-claim,
? manifests-claim,
? swevidence-claim,
? submods-part, ? submods-part,
* $$eat-extension, * $$eat-extension,
} }
; This is the top-level definition of an EAT Token. It is a CWT, JWT ; This is the top-level definition of an EAT Token. It is a CWT, JWT
; or UCSS where the payload is an eat-claim-set. A JWT_Message is what ; or UCSS where the payload is an eat-claim-set. A JWT_Message is what
; is defined by JWT in RFC 7519. (RFC 7519 doesn't use CDDL so a there ; is defined by JWT in RFC 7519. (RFC 7519 doesn't use CDDL so a there
; is no actual CDDL definition of JWT_Message). ; is no actual CDDL definition of JWT_Message).
eat-token = EAT_Tagged_Message / EAT_Untagged_Message / JWT_Message eat-token = EAT_Tagged_Message / EAT_Untagged_Message / JWT_Message
skipping to change at page 35, line 44 skipping to change at page 43, line 32
) )
issuer = 1 issuer = 1
subject = 2 subject = 2
audience = 3 audience = 3
expiration = 4 expiration = 4
not-before = 5 not-before = 5
issued-at = 6 issued-at = 6
cwt-id = 7 cwt-id = 7
debug-status-type = &( debug-status-cbor-type = &(
enabled: 0, enabled: 0,
disabled: 1, disabled: 1,
disabled-since-boot: 2, disabled-since-boot: 2,
disabled-permanently: 3, disabled-permanently: 3,
disabled-fully-and-permanently: 4 disabled-fully-and-permanently: 4
) )
debug-status-json-type =
"enabled" /
"disabled" /
"disabled-since-boot" /
"disabled-permanently" /
"disabled-fully-and-permanently"
debug-status-claim = ( debug-status-claim = (
debug-status => debug-status-type debug-status => debug-status-cbor-type / debug-status-json-type
) )
location-type = { location-type = {
latitude => number, latitude => number,
longitude => number, longitude => number,
? altitude => number, ? altitude => number,
? accuracy => number, ? accuracy => number,
? altitude-accuracy => number, ? altitude-accuracy => number,
? heading => number, ? heading => number,
? speed => number, ? speed => number,
? timestamp => ~time-int, ? timestamp => ~time-int,
? age => uint ? age => uint
} }
latitude = 1 latitude = 1 / "latitude"
longitude = 2 longitude = 2 / "longitude"
altitude = 3 altitude = 3 / "altitude"
accuracy = 4 accuracy = 4 / "accuracy"
altitude-accuracy = 5 altitude-accuracy = 5 / "altitude-accuracy"
heading = 6 heading = 6 / "heading"
speed = 7 speed = 7 / "speed"
timestamp = 8 timestamp = 8 / "timestamp"
age = 9 age = 9 / "age"
location-claim = ( location-claim = (
location => location-type location-label => location-type
) )
nonce-type = bstr .size (8..64) nonce-type = bstr .size (8..64)
nonce-claim = ( nonce-claim = (
nonce => nonce-type / [ 2* nonce-type ] nonce => nonce-type / [ 2* nonce-type ]
) )
oemid-claim = ( oemid-claim = (
oemid => bstr oemid => bstr
) )
; copied from CoSWID
; TODO: how to properly make reference to CoSWID and have tool validate
$version-scheme /= multipartnumeric
$version-scheme /= multipartnumeric-suffix
$version-scheme /= alphanumeric
$version-scheme /= decimal
$version-scheme /= semver
$version-scheme /= uint / text
multipartnumeric = 1
multipartnumeric-suffix = 2
alphanumeric = 3
decimal = 4
semver = 16384
chip-version-claim = ( chip-version-claim = (
chip-version => tstr chip-version => tstr
) )
chip-version-scheme-claim = ( chip-version-scheme-claim = (
chip-version-scheme => $version-scheme chip-version-scheme => $version-scheme
) )
board-version-claim = ( board-version-claim = (
board-version => tstr board-version => tstr
skipping to change at page 37, line 33 skipping to change at page 45, line 11
) )
device-version-claim = ( device-version-claim = (
device-version => tstr device-version => tstr
) )
device-version-scheme-claim = ( device-version-scheme-claim = (
device-version-scheme => $version-scheme device-version-scheme => $version-scheme
) )
ean-type = text .regexp "[0-9]{13}"
ean-chip-version-claim = (
ean-chip-version => ean-type
)
ean-board-version-claim = (
ean-board-version => ean-type
)
ean-device-version-claim = (
ean-device-version => ean-type
)
hardware-version-claims = ( hardware-version-claims = (
? chip-version-claim, ? chip-version-claim,
? board-version-claim, ? board-version-claim,
? device-version-claim, ? device-version-claim,
? chip-version-scheme-claim, ? chip-version-scheme-claim,
? board-version-scheme-claim, ? board-version-scheme-claim,
? device-version-scheme-claim, ? device-version-scheme-claim,
? ean-chip-version-claim,
? ean-board-version-claim,
? ean-device-version-claim,
) )
origination-claim = (
origination => string-or-uri
)
secure-boot-claim = ( secure-boot-claim = (
secure-boot => bool secure-boot => bool
) )
security-level-type = &( security-level-cbor-type = &(
unrestricted: 1, unrestricted: 1,
restricted: 2, restricted: 2,
secure-restricted: 3, secure-restricted: 3,
hardware: 4 hardware: 4
) )
security-level-json-type =
"unrestricted" /
"restricted" /
"secure-restricted" /
"hardware"
security-level-claim = ( security-level-claim = (
security-level => security-level-type security-level => security-level-cbor-type / security-level-json-type
) )
; The part of a token that contains all the submodules. It is a peer ; The part of a token that contains all the submodules. It is a peer
; with the claims in the token, but not a claim, only a map/object to ; with the claims in the token, but not a claim, only a map/object to
; hold all the submodules. ; hold all the submodules.
submods-part = ( submods-part = (
submods => submods-type submods => submods-type
) )
submods-type = { + submod-type } submods-type = { + submod-type }
skipping to change at page 39, line 16 skipping to change at page 46, line 26
; Each submodule has a unique text string name. ; Each submodule has a unique text string name.
submod-name = tstr submod-name = tstr
ueid-type = bstr .size (7..33) ueid-type = bstr .size (7..33)
ueid-claim = ( ueid-claim = (
ueid => ueid-type ueid => ueid-type
) )
intended-use-type = &( sueids-type = {
+ tstr => ueid-type
}
sueids-claim = (
sueids => sueids-type
)
intended-use-cbor-type = &(
generic: 1, generic: 1,
registration: 2, registration: 2,
provisioning: 3, provisioning: 3,
csr: 4, csr: 4,
pop: 5 pop: 5
) )
intended-use-json-type =
"generic" /
"registration" /
"provisioning" /
"csr" /
"pop"
intended-use-claim = ( intended-use-claim = (
intended-use => intended-use-type intended-use => intended-use-cbor-type / intended-use-json-type
) )
oid = #6.4000(bstr) ; TODO: fill this in with correct CDDL from OID RFC
uptime-claim = ( uptime-claim = (
uptime => uint uptime => uint
) )
; The following Claim Keys (labels) are pre-assigned by IANA.
; They are for CBOR-based tokens (CWT and UCCS).
; They are not expected to change in the final publication as an RFC.
nonce = 10 manifests-claim = (
ueid = 11 manifests => manifests-type
oemid = 13 )
security-level = 14
secure-boot = 15
debug-status = 16
location = 17
profile = 18
submods = 20
; These are not yet assigned in any way and may change. manifests-type = [+ $manifest-formats]
; These are intentionally above 24 so as to not use up
; single-byte labels.
origination = <TBD30> ; Must be a CoSWID payload type
uptime = <TBD31> $manifest-formats /= bytes .cbor concise-swid-tag
chip-version = <TBD32>
board-version = <TBD33>
device-version = <TBD34>
chip-version-scheme = <TBD35>
board-version-scheme = <TBD36>
device-version-scheme = <TBD37>
ean-chip-version = <TBD38>
ean-board-version = <TBD39>
ean-device-version = <TBD40>
intended-use = <TBD41>
; The following are Claim Keys (labels) assigned for JSON-encoded tokens.
ueid /= "ueid" $manifest-formats /= bytes .cbor SUIT_Envelope_Tagged
nonce /= "nonce"
origination /= "origination"
oemid /= "oemid"
security-level /= "seclevel"
secure-boot /= "secboot"
debug-status /= "dbgstat"
location /= "location"
uptime /= "uptime"
profile /= "eat-profile"
intended-use /= "intuse"
boot-seed /= "bootseed"
submods /= "submods"
timestamp /= "timestamp"
latitude /= "lat" swevidence-claim = (
longitude /= "long" swevidence => swevidence-type
altitude /= "alt" )
accuracy /= "accry"
altitude-accuracy /= "alt-accry" swevidence-type = [+ $swevidence-formats]
heading /= "heading"
speed /= "speed" ; Must be a CoSWID evidence type
$swevidence-formats /= bytes .cbor concise-swid-tag
oid = #6.4000(bstr) ; TODO: fill this in with correct CDDL from OID RFC
profile-claim = (
profile => ~uri / ~oid
)
boot-seed-claim = (
boot-seed => bytes
)
7. IANA Considerations 7. IANA Considerations
7.1. Reuse of CBOR Web Token (CWT) Claims Registry 7.1. Reuse of CBOR Web Token (CWT) Claims Registry
Claims defined for EAT are compatible with those of CWT so the CWT Claims defined for EAT are compatible with those of CWT so the CWT
Claims Registry is re used. No new IANA registry is created. All Claims Registry is re used. No new IANA registry is created. All
EAT claims should be registered in the CWT and JWT Claims Registries. EAT claims should be registered in the CWT and JWT Claims Registries.
7.2. Claim Characteristics 7.2. Claim Characteristics
skipping to change at page 46, line 9 skipping to change at page 53, line 14
o Claim Value Type(s): map o Claim Value Type(s): map
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): *this document* o Specification Document(s): *this document*
7.3.2. To be Assigned Claims 7.3.2. To be Assigned Claims
TODO: add the rest of the claims in here TODO: add the rest of the claims in here
7.3.3. Version Schemes Registered by this Document
IANA is requested to register a new value in the "Software Tag
Version Scheme Values" established by [CoSWID].
The new value is a version scheme a 13-digit European Article Number
[EAN-13]. An EAN-13 is also known as an International Article Number
or most commonly as a bar code. This version scheme is the ASCII
text representation of EAN-13 digits, the same ones often printed
with a bar code. This version scheme must comply with the EAN
allocation and assignment rules. For example, this requires the
manufacturer to obtain a manufacture code from GS1.
+-------+---------------------+---------------+
| Index | Version Scheme Name | Specification |
+-------+---------------------+---------------+
| 5 | ean-13 | This document |
+-------+---------------------+---------------+
8. Privacy Considerations 8. Privacy Considerations
Certain EAT claims can be used to track the owner of an entity and Certain EAT claims can be used to track the owner of an entity and
therefore, implementations should consider providing privacy- therefore, implementations should consider providing privacy-
preserving options dependent on the intended usage of the EAT. preserving options dependent on the intended usage of the EAT.
Examples would include suppression of location claims for EAT's Examples would include suppression of location claims for EAT's
provided to unauthenticated consumers. provided to unauthenticated consumers.
8.1. UEID Privacy Considerations 8.1. UEID and SUEID Privacy Considerations
A UEID is usually not privacy-preserving. Any set of relying parties A UEID is usually not privacy-preserving. Any set of relying parties
that receives tokens that happen to be from a single device will be that receives tokens that happen to be from a single device will be
able to know the tokens are all from the same device and be able to able to know the tokens are all from the same device and be able to
track the device. Thus, in many usage situations ueid violates track the device. Thus, in many usage situations UEID violates
governmental privacy regulation. In other usage situations UEID will governmental privacy regulation. In other usage situations a UEID
not be allowed for certain products like browsers that give privacy will not be allowed for certain products like browsers that give
for the end user. It will often be the case that tokens will not privacy for the end user. It will often be the case that tokens will
have a UEID for these reasons. not have a UEID for these reasons.
An SUEID is also usually not privacy-preserving. In some cases it
may have fewer privacy issues than a UEID depending on when and how
and when it is generated.
There are several strategies that can be used to still be able to put There are several strategies that can be used to still be able to put
UEID's in tokens: UEIDs and SUEIDs in tokens:
o The device obtains explicit permission from the user of the device o The device obtains explicit permission from the user of the device
to use the UEID. This may be through a prompt. It may also be to use the UEID/SUEID. This may be through a prompt. It may also
through a license agreement. For example, agreements for some be through a license agreement. For example, agreements for some
online banking and brokerage services might already cover use of a online banking and brokerage services might already cover use of a
UEID. UEID/SUEID.
o The UEID is used only in a particular context or particular use o The UEID/SUEID is used only in a particular context or particular
case. It is used only by one relying party. use case. It is used only by one relying party.
o The device authenticates the relying party and generates a derived o The device authenticates the relying party and generates a derived
UEID just for that particular relying party. For example, the UEID/SUEID just for that particular relying party. For example,
relying party could prove their identity cryptographically to the the relying party could prove their identity cryptographically to
device, then the device generates a UEID just for that relying the device, then the device generates a UEID just for that relying
party by hashing a proofed relying party ID with the main device party by hashing a proofed relying party ID with the main device
UEID. UEID/SUEID.
Note that some of these privacy preservation strategies result in Note that some of these privacy preservation strategies result in
multiple UEIDs per device. Each UEID is used in a different context, multiple UEIDs and SUEIDs per device. Each UEID/SUEID is used in a
use case or system on the device. However, from the view of the different context, use case or system on the device. However, from
relying party, there is just one UEID and it is still globally the view of the relying party, there is just one UEID and it is still
universal across manufacturers. globally universal across manufacturers.
8.2. Location Privacy Considerations 8.2. Location Privacy Considerations
Geographic location is most always considered personally identifiable Geographic location is most always considered personally identifiable
information. Implementers should consider laws and regulations information. Implementers should consider laws and regulations
governing the transmission of location data from end user devices to governing the transmission of location data from end user devices to
servers and services. Implementers should consider using location servers and services. Implementers should consider using location
management facilities offered by the operating system on the device management facilities offered by the operating system on the device
generating the attestation. For example, many mobile phones prompt generating the attestation. For example, many mobile phones prompt
the user for permission when before sending location data. the user for permission when before sending location data.
skipping to change at page 49, line 10 skipping to change at page 56, line 36
a nested EAT. Then transport security between the receiving and a nested EAT. Then transport security between the receiving and
downstream consumers is not strictly required. Nevertheless, downstream consumers is not strictly required. Nevertheless,
downstream consumers of a nested EAT should provide a nonce unique to downstream consumers of a nested EAT should provide a nonce unique to
the EAT they are consuming. the EAT they are consuming.
10. References 10. References
10.1. Normative References 10.1. Normative References
[CBOR-OID] [CBOR-OID]
Bormann, C. and S. Leonard, "Concise Binary Object Bormann, C., "Concise Binary Object Representation (CBOR)
Representation (CBOR) Tags for Object Identifiers", draft- Tags for Object Identifiers", draft-ietf-cbor-tags-oid-06
ietf-cbor-tags-oid-04 (work in progress), January 2021. (work in progress), March 2021.
[CBOR.Cert.Draft]
Raza, S., "CBOR Encoding of X.509 Certificates (CBOR
Certificates)", 2020, <https://tools.ietf.org/html/draft-
mattsson-cose-cbor-cert-compress-05>.
[COSE.X509.Draft]
Schaad, J., "CBOR Object Signing and Encryption (COSE):
Header parameters for carrying and referencing X.509
certificates", 2020,
<https://tools.ietf.org/html/draft-ietf-cose-x509-08>.
[CoSWID] "Concise Software Identification Tags", November 2020, [CoSWID] "Concise Software Identification Tags", November 2020,
<https://tools.ietf.org/html/draft-ietf-sacm-coswid-16>. <https://tools.ietf.org/html/draft-ietf-sacm-coswid-16>.
[EAN-13] GS1, "International Article Number - EAN/UPC barcodes", [EAN-13] GS1, "International Article Number - EAN/UPC barcodes",
2019, <https://www.gs1.org/standards/barcodes/ean-upc>. 2019, <https://www.gs1.org/standards/barcodes/ean-upc>.
[FIDO.AROE] [FIDO.AROE]
The FIDO Alliance, "FIDO Authenticator Allowed Restricted The FIDO Alliance, "FIDO Authenticator Allowed Restricted
Operating Environments List", November 2019, Operating Environments List", November 2019,
skipping to change at page 49, line 40 skipping to change at page 57, line 28
[IANA.JWT.Claims] [IANA.JWT.Claims]
IANA, "JSON Web Token (JWT) Claims", IANA, "JSON Web Token (JWT) Claims",
<https://www.iana.org/assignments/jwt>. <https://www.iana.org/assignments/jwt>.
[OpenIDConnectCore] [OpenIDConnectCore]
Sakimura, N., Bradley, J., Jones, M., Medeiros, B. D., and Sakimura, N., Bradley, J., Jones, M., Medeiros, B. D., and
C. Mortimore, "OpenID Connect Core 1.0 incorporating C. Mortimore, "OpenID Connect Core 1.0 incorporating
errata set 1", November 2014, errata set 1", November 2014,
<https://openid.net/specs/openid-connect-core-1_0.html>. <https://openid.net/specs/openid-connect-core-1_0.html>.
[RATS-Architecture]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote Attestation Procedures Architecture",
draft-ietf-rats-architecture-12 (work in progress), April
2021.
[RATS.Architecture]
Birkholz, H., "Remote Attestation Procedures
Architecture", 2020, <https://tools.ietf.org/html/draft-
ietf-rats-architecture-08>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015, DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/info/rfc7517>. <https://www.rfc-editor.org/info/rfc7517>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
Possession Key Semantics for JSON Web Tokens (JWTs)", Possession Key Semantics for JSON Web Tokens (JWTs)",
skipping to change at page 51, line 43 skipping to change at page 60, line 5
The FIDO Alliance, "FIDO Registry of Predefined Values", The FIDO Alliance, "FIDO Registry of Predefined Values",
December 2019, <https://fidoalliance.org/specs/common- December 2019, <https://fidoalliance.org/specs/common-
specs/fido-registry-v2.1-ps-20191217.html>. specs/fido-registry-v2.1-ps-20191217.html>.
[FIPS-140] [FIPS-140]
National Institue of Standards, "Security Requirements for National Institue of Standards, "Security Requirements for
Cryptographic Modules", May 2001, Cryptographic Modules", May 2001,
<https://csrc.nist.gov/publications/detail/fips/140/2/ <https://csrc.nist.gov/publications/detail/fips/140/2/
final>. final>.
[IDevID] "IEEE Standard, "IEEE 802.1AR Secure Device Identifier"",
December 2009, <http://standards.ieee.org/findstds/
standard/802.1AR-2009.html>.
[IEEE.802-2001] [IEEE.802-2001]
"IEEE Standard For Local And Metropolitan Area Networks "IEEE Standard For Local And Metropolitan Area Networks
Overview And Architecture", 2007, Overview And Architecture", 2007,
<https://webstore.ansi.org/standards/ieee/ <https://webstore.ansi.org/standards/ieee/
ieee8022001r2007>. ieee8022001r2007>.
[IEEE.802.1AR]
"IEEE Standard, "IEEE 802.1AR Secure Device Identifier"",
December 2009, <http://standards.ieee.org/findstds/
standard/802.1AR-2009.html>.
[IEEE.RA] "IEEE Registration Authority", [IEEE.RA] "IEEE Registration Authority",
<https://standards.ieee.org/products-services/regauth/ <https://standards.ieee.org/products-services/regauth/
index.html>. index.html>.
[OUI.Guide] [OUI.Guide]
"Guidelines for Use of Extended Unique Identifier (EUI), "Guidelines for Use of Extended Unique Identifier (EUI),
Organizationally Unique Identifier (OUI), and Company ID Organizationally Unique Identifier (OUI), and Company ID
(CID)", August 2017, (CID)", August 2017,
<https://standards.ieee.org/content/dam/ieee- <https://standards.ieee.org/content/dam/ieee-
standards/standards/web/documents/tutorials/eui.pdf>. standards/standards/web/documents/tutorials/eui.pdf>.
skipping to change at page 57, line 9 skipping to change at page 65, line 9
entropy. entropy.
UUIDs seem to have been designed for scenarios where the implementor UUIDs seem to have been designed for scenarios where the implementor
does not have full control over the environment and uniqueness has to does not have full control over the environment and uniqueness has to
be constructed from identifiers at hand. UEID takes the view that be constructed from identifiers at hand. UEID takes the view that
hardware, software and/or manufacturing process directly implement hardware, software and/or manufacturing process directly implement
UEID in a simple and direct way. It takes the view that UEID in a simple and direct way. It takes the view that
cryptographic quality random number generators are readily available cryptographic quality random number generators are readily available
as they are implemented in commonly used CPU hardware. as they are implemented in commonly used CPU hardware.
Appendix C. Changes from Previous Drafts Appendix C. EAT Relation to IEEE.802.1AR Secure Device Identity (DevID)
This section describes several distinct ways in which an IEEE IDevID
[IEEE.802.1AR] relates to EAT, particularly to UEID and SUEID.
[IEEE.802.1AR] orients around the definition of an implementation
called a "DevID Module." It describes how IDevIDs and LDevIDs are
stored, protected and accessed using a DevID Module. A particular
level of defense against attack that should be achieved to be a DevID
is defined. The intent is that IDevIDs and LDevIDs are used with an
open set of network protocols for authentication and such. In these
protocols the DevID secret is used to sign a nonce or similar to
proof the association of the DevID certificates with the device.
By contrast, EAT defines network protocol for proving trustworthiness
to a relying party, the very thing that is not defined in
[IEEE.802.1AR]. Nor does not give details on how keys, data and such
are stored protected and accessed. EAT is intended to work with a
variety of different on-device implementations ranging from minimal
protection of assets to the highest levels of asset protection. It
does not define any particular level of defense against attack,
instead providing a set of security considerations.
EAT and DevID can be viewed as complimentary when used together or as
competing to provide a device identity service.
C.1. DevID Used With EAT
As just described, EAT defines a network protocol and [IEEE.802.1AR]
doesn't. Vice versa, EAT doesn't define a an device implementation
and DevID does.
Hence, EAT can be the network protocol that a DevID is used with.
The DevID secret becomes the attestation key used to sign EATs. The
DevID and its certificate chain become the Endorsement sent to the
Verifier.
In this case the EAT and the DevID are likely to both provide a
device identifier (e.g. a serial number). In the EAT it is the UEID
(or SUEID). In the DevID (used as an endorsement), it is a device
serial number included in the subject field of the DevID certificate.
It is probably a good idea in this use for them to be the same serial
number or for the UEID to be a hash of the DevID serial number.
C.2. How EAT Provides an Equivalent Secure Device Identity
The UEID, SUEID and other claims like OEM ID are equivalent to the
secure device identity put into the subject field of a DevID
certificate. These EAT claims can represent all the same fields and
values that can be put in a DevID certificate subject. EAT
explicitly and carefully defines a variety of useful claims.
EAT secures the conveyance of these claims by having them signed on
the device by the attestation key when the EAT is generated. EAT
also signs the nonce that gives freshness at this time. Since these
claims are signed for every EAT generated, they can include things
that vary over time like GPS location.
DevID secures the device identity fields by having them signed by the
manufacturer of the device sign them into a certificate. That
certificate is created once during the manufacturing of the device
and never changes so the fields cannot change.
So in one case the signing of the identity happens on the device and
the other in a manufacturing facility, but in both cases the signing
of the nonce that proves the binding to the actual device happens on
the device.
While EAT does not specify how the signing keys, signature process
and storage of the identity values should be secured against attack,
an EAT implementation may have equal defenses against attack. One
reason EAT uses CBOR is because it is simple enough that a basic EAT
implementation can be constructed entirely in hardware. This allows
EAT to be implemented with the strongest defenses possible.
C.3. An X.509 Format EAT
It is possible to define a way to encode EAT claims in an X.509
certificate. For example, the EAT claims might be mapped to X.509 v3
extensions. It is even possible to stuff a whole CBOR-encoded
unsigned EAT token into a X.509 certificate.
If that X.509 certificate is an IDevID or LDevID, this becomes
another way to use EAT and DevID together.
Note that the DevID must still be used with an authentication
protocol that has a nonce or equivalent. The EAT here is not being
used as the protocol to interact with the rely party.
C.4. Device Identifier Permanence
In terms of permanence, an IDevID is similar to a UEID in that they
do not change over the life of the device. They cease to exist only
when the device is destroyed.
An SUEID is similar to an LDevID. They change on device life-cycle
events.
[IEEE.802.1AR] describes much of this permanence as resistant to
attacks that seek to change the ID. IDevID permanence can be
described this way because [IEEE.802.1AR] is oriented around the
definition of an implementation with a particular level of defense
against attack.
EAT is not defined around a particular implementation and must work
on a range of devices that have a range of defenses against attack.
EAT thus can't be defined permanence in terms of defense against
attack. EAT's definition of permanence is in terms of operations and
device lifecycle.
Appendix D. Changes from Previous Drafts
The following is a list of known changes from the previous drafts. The following is a list of known changes from the previous drafts.
This list is non-authoritative. It is meant to help reviewers see This list is non-authoritative. It is meant to help reviewers see
the significant differences. the significant differences.
C.1. From draft-rats-eat-01 D.1. From draft-rats-eat-01
o Added UEID design rationale appendix o Added UEID design rationale appendix
C.2. From draft-mandyam-rats-eat-00 D.2. From draft-mandyam-rats-eat-00
This is a fairly large change in the orientation of the document, but This is a fairly large change in the orientation of the document, but
no new claims have been added. no new claims have been added.
o Separate information and data model using CDDL. o Separate information and data model using CDDL.
o Say an EAT is a CWT or JWT o Say an EAT is a CWT or JWT
o Use a map to structure the boot_state and location claims o Use a map to structure the boot_state and location claims
C.3. From draft-ietf-rats-eat-01 D.3. From draft-ietf-rats-eat-01
o Clarifications and corrections for OEMID claim o Clarifications and corrections for OEMID claim
o Minor spelling and other fixes o Minor spelling and other fixes
o Add the nonce claim, clarify jti claim o Add the nonce claim, clarify jti claim
C.4. From draft-ietf-rats-eat-02 D.4. From draft-ietf-rats-eat-02
o Roll all EUIs back into one UEID type o Roll all EUIs back into one UEID type
o UEIDs can be one of three lengths, 128, 192 and 256. o UEIDs can be one of three lengths, 128, 192 and 256.
o Added appendix justifying UEID design and size. o Added appendix justifying UEID design and size.
o Submods part now includes nested eat tokens so they can be named o Submods part now includes nested eat tokens so they can be named
and there can be more tha one of them and there can be more tha one of them
o Lots of fixes to the CDDL o Lots of fixes to the CDDL
o Added security considerations o Added security considerations
C.5. From draft-ietf-rats-eat-03 D.5. From draft-ietf-rats-eat-03
o Split boot_state into secure-boot and debug-disable claims o Split boot_state into secure-boot and debug-disable claims
o Debug disable is an enumerated type rather than Booleans o Debug disable is an enumerated type rather than Booleans
C.6. From draft-ietf-rats-eat-04 D.6. From draft-ietf-rats-eat-04
o Change IMEI-based UEIDs to be encoded as a 14-byte string o Change IMEI-based UEIDs to be encoded as a 14-byte string
o CDDL cleaned up some more o CDDL cleaned up some more
o CDDL allows for JWTs and UCCSs o CDDL allows for JWTs and UCCSs
o CWT format submodules are byte string wrapped o CWT format submodules are byte string wrapped
o Allows for JWT nested in CWT and vice versa o Allows for JWT nested in CWT and vice versa
skipping to change at page 58, line 43 skipping to change at page 69, line 12
o Rename debug-disable to debug-status; clarify that it is not o Rename debug-disable to debug-status; clarify that it is not
extensible extensible
o Security level claim is not extensible o Security level claim is not extensible
o Improve specification of location claim and added a location o Improve specification of location claim and added a location
privacy section privacy section
o Add intended use claim o Add intended use claim
C.7. From draft-ietf-rats-05 D.7. From draft-ietf-rats-05
o CDDL format issues resolved o CDDL format issues resolved
o Corrected reference to Location Privacy section o Corrected reference to Location Privacy section
C.8. From draft-ietf-rats-06 D.8. From draft-ietf-rats-06
o Added boot-seed claim o Added boot-seed claim
o Rework CBOR interoperability section o Rework CBOR interoperability section
o Added profiles claim and section o Added profiles claim and section
C.9. From draft-ietf-rats-07 D.9. From draft-ietf-rats-07
o Filled in IANA and other sections for possible preassignment of o Filled in IANA and other sections for possible preassignment of
claim keys for well understood claims claim keys for well understood claims
C.10. From draft-ietf-rats-08 D.10. From draft-ietf-rats-08
o Change profile claim to be either a URL or an OID rather than a o Change profile claim to be either a URL or an OID rather than a
test string test string
D.11. From draft-ietf-rats-09
o Add SUEIDs
o Add appendix comparing IDevID to EAT
o Added section on use for Evidence and Attestation Results
o Fill in the key ID and endorsements identificaiton section
o Remove origination claim as it is replaced by key IDs and
endorsements
o Added manifests and software evidence claims
o Add string labels non-claim labels for use with JSON (e.g. labels
for members of location claim)
o EAN-13 HW versions are no longer a separate claim. Now they are
folded in as a CoSWID version scheme.
Authors' Addresses Authors' Addresses
Giridhar Mandyam Giridhar Mandyam
Qualcomm Technologies Inc. Qualcomm Technologies Inc.
5775 Morehouse Drive 5775 Morehouse Drive
San Diego, California San Diego, California
USA USA
Phone: +1 858 651 7200 Phone: +1 858 651 7200
EMail: mandyam@qti.qualcomm.com EMail: mandyam@qti.qualcomm.com
 End of changes. 130 change blocks. 
393 lines changed or deleted 844 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/