idnits 2.17.1 draft-xyz-rats-psa-endorsements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (12 July 2021) is 1018 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-birkholz-rats-corim-00 == Outdated reference: A later version (-22) exists of draft-tschofenig-rats-psa-token-08 ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-12 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS T. Fossati 3 Internet-Draft Y. Deshpande 4 Intended status: Informational Arm Ltd 5 Expires: 13 January 2022 H. Birkholz 6 Fraunhofer SIT 7 12 July 2021 9 Arm's Platform Security Architecture (PSA) Attestation Verifier 10 Endorsements 11 draft-xyz-rats-psa-endorsements-00 13 Abstract 15 PSA Endorsements include reference values, cryptographic key material 16 and certification status information that a Verifier needs in order 17 to appraise attestation Evidence produced by a PSA device. This memo 18 defines such PSA Endorsements as a profile of the CoRIM data model. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 13 January 2022. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 2 55 3. PSA Endorsements . . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. PSA Endorsements to PSA RoT Linkage . . . . . . . . . . . 3 57 3.2. Reference Values . . . . . . . . . . . . . . . . . . . . 4 58 3.3. Attestation Verification Claims . . . . . . . . . . . . . 6 59 3.4. Certification Claims . . . . . . . . . . . . . . . . . . 8 60 3.5. Endorsements Block List . . . . . . . . . . . . . . . . . 9 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 64 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 Normative References . . . . . . . . . . . . . . . . . . . . . 9 66 Informative References . . . . . . . . . . . . . . . . . . . . 10 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 69 1. Introduction 71 PSA Endorsements include reference values, cryptographic key material 72 and certification status information that a Verifier needs in order 73 to appraise attestation Evidence produced by a PSA device 74 [PSA-TOKEN]. This memo defines such PSA Endorsements as a profile of 75 the CoRIM data model [CoRIM]. 77 2. Conventions and Definitions 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 81 "OPTIONAL" in this document are to be interpreted as described in 82 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 83 capitals, as shown here. 85 The reader is assumed to be familiar with the terms defined in 86 Section 2.1 of [PSA-TOKEN] and in Section 4 of [RATS-ARCH]. 88 3. PSA Endorsements 90 PSA Endorsements describe an attesting device in terms of the 91 hardware and firmware components that make up its PSA Root of Trust 92 (RoT). This includes the identification and expected state of the 93 device as well as the cryptographic key material needed to verify 94 Evidence signed by the device's PSA RoT. Additionally, PSA 95 Endorsements can include information related to the certification 96 status of the attesting device. 98 There are three basic types of PSA Endorsements: 100 * Reference Values (Section 3.2), i.e., measurements of the PSA RoT 101 firmware; 103 * Attestation Verification Claims (Section 3.3), i.e., cryptographic 104 keys that can be used to verify signed Evidence produced by the 105 PSA RoT, along with the identifiers that bind the keys to their 106 device instances; 108 * Certification Claims (Section 3.4), i.e., metadata that describe 109 the certification status associated with a PSA device. 111 There is also a fourth category of PSA Endorsements: 113 * Endorsements Block List (Section 3.5), 115 that is used to invalidate previously provisioned Endorsements. 117 3.1. PSA Endorsements to PSA RoT Linkage 119 Each PSA Endorsement - be it a Reference Value, Attestation 120 Verification Claim or Certification Claim - is associated with an 121 immutable PSA RoT. A PSA Endorsement is associated to its PSA RoT by 122 means of the unique PSA RoT identifier known as Implementation ID 123 (see Section 3.2.2 of [PSA-TOKEN]). Besides, a PSA Endorsement can 124 be associated with a specific instance of a certain PSA RoT - as in 125 the case of Attestation Verification Claims. A PSA Endorsement is 126 associated with a PSA RoT instance by means of the Instance ID (see 127 Section 3.2.1 of [PSA-TOKEN]) and its "parent" Implementation ID. 129 These identifiers are typically found in the subject of a CoMID 130 triple, encoded in an "environment-map" as shown in Figure 1. 132 / environment-map / { 133 / comid.class / 0 : { 134 / comid.class-id / 0 : 135 / tagged-impl-id-type / 47115( 136 h'61636d652d696d706c656d656e746174696f6e2d69642d303030303030 137 303031' 138 ) 139 }, 140 / comid.instance / 1 : 141 / tagged-ueid-type / 48000( 142 h'014ca3e4f50bf248c39787020d68ffd05c88767751bf2645ca923f57a98b 143 ecd296' 144 ) 145 } 147 Figure 1: Example PSA RoT Identification 149 3.2. Reference Values 151 Reference Values carry measurements and other metadata associated 152 with the updatable firmware in a PSA RoT. When appraising Evidence, 153 the Verifier compares Reference Values against the values found in 154 the Software Components of the PSA token (see Section 3.4.1 of 155 [PSA-TOKEN]). 157 Each measurement is encoded in a "measurement-map" of a CoMID 158 "reference-triple-record". Since a "measurement-map" can encode one 159 or more measurements, a single "reference-triple-record" can carry as 160 many measurements as needed, provided they belong to the same PSA RoT 161 carried in the subject of the "reference value" triple. 163 The identifier of a measurement is encoded in a "psa-refval-id" 164 object as follows: 166 psa-refval-id = { 167 ? psa.measurement-type => text 168 ? psa.version => text 169 psa.signer-id => psa.hash-type 170 ? psa.measurement-desc => text 171 } 173 psa.hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64 175 psa.measurement-type = 1 176 psa.version = 4 177 psa.signer-id = 5 178 psa.measurement-desc = 6 179 The semantics of the codepoints in the "psa-refval-id" map are 180 equivalent to those in the "psa-software-component" map defined in 181 Section 3.4.1 of [PSA-TOKEN]. 183 In order to support PSA Reference Value identifiers, the "$measured- 184 element-type-choice" CoMID type is extended as follows: 186 tagged-psa-refval-id = #6.TBD(psa-refval-id) 188 $measured-element-type-choice /= tagged-psa-refval-id 190 and automatically bound to the "comid.mkey" in the "measurement-map". 192 The raw measurement is encoded in a "digests-type" object in the 193 "measurements-value-map". The "digests-type" array MUST contain only 194 one entry. If multiple digests of the same measured component exist 195 (obtained with different hash algorithms), a different 196 "psa.measurement-desc" MUST be used in the identifier. 198 The example in Figure 2 shows the PSA Endorsement of type Reference 199 Value for a firmware measurement associated with Implementation ID 200 "acme-implementation-id-000000001". 202 / concise-mid-tag / { 203 / comid.tag-identity / 1 : { 204 / comid.tag-id / 0 : h'3f06af63a93c11e4979700505690773f' 205 }, 206 / comid.triples / 4 : { 207 / comid.reference-triples / 0 : [ 208 / environment-map / { 209 / comid.class / 0 : { 210 / comid.class-id / 0 : 211 / tagged-impl-id-type / 47115( 212 h'61636d652d696d706c656d656e746174696f6e2d69642d303030 213 303030303031' 214 ) 215 } 216 }, 217 / measurement-map / { 218 / comid.mkey / 0 : TBD({ 219 / psa.measurement-type / 1 : "PRoT", 220 / psa.version / 4 : "1.3.5", 221 / psa.signer-id / 5 : h'acbb11c7e4da217205523ce4ce1 222 a245ae1a239ae3c6bfd9e7871f7e5d8bae86b' 223 }), 224 / comid.mval / 1 : { 225 / comid.digests / 2 : [ 226 / hash-alg-id / 1, / sha256 / 227 / hash-value / h'44aa336af4cb14a879432e53dd6571c7fa9bcc 228 afb75f488259262d6ea3a4d91b' 229 ] 230 } 231 } 232 ] 233 } 234 } 236 Figure 2: Example Reference Value 238 3.3. Attestation Verification Claims 240 An Attestation Verification Claim carries the verification key 241 associated with the Initial Attestation Key (IAK) of a PSA device. 242 When appraising Evidence, the Verifier uses the Implementation ID and 243 Instance ID claims (see Section 3.1) to retrieve the verification key 244 that it must use to check the signature on the Evidence. This allows 245 the Verifier to prove (or disprove) the Attester's claimed identity. 247 Each verification key is provided alongside the corresponding device 248 Instance and Implementation IDs in an "attest-key-triple-record". 249 Specifically: 251 * The Instance and Implementation IDs are encoded in the 252 environment-map as shown in Figure 1; 254 * The IAK public key is carried in the "comid.key" entry in the 255 "verification-key-map". The IAK public key is encoded as a 256 COSE_Key according to Section 7 of [RFC8152]. There MUST be only 257 one "verification-key-map" in an "identity-triple-record"; 259 * The optional "comid.keychain" entry MUST NOT be set by a producer 260 and MUST be ignored by a consumer. 262 The example in Figure 3 shows the PSA Endorsement of type Attestation 263 Verification Claim carrying a secp256r1 EC public IAK associated with 264 Instance ID "4ca3...d296". 266 / concise-mid-tag / { 267 / comid.tag-identity / 1 : { 268 / comid.tag-id / 0 : h'3f06af63a93c11e4979700505690773f' 269 }, 270 / comid.triples / 4 : { 271 / comid.attest-key-triples / 3 : [ 272 / environment-map / { 273 / comid.class / 0 : { 274 / comid.class-id / 0 : 275 / tagged-impl-id-type / 47115( 276 h'61636d652d696d706c656d656e746174696f6e2d69642d303030 277 303030303031' 278 ) 279 }, 280 / comid.instance / 1 : 281 / tagged-ueid-type / 48000( 282 h'014ca3e4f50bf248c39787020d68ffd05c88767751bf2645ca923f 283 57a98becd296' 284 ) 285 }, 286 / verification-key-map / { 287 / comid.key / 0 : { 288 / kty / 1 : 2, / EC2 / 289 / crv / -1 : 1, / P-256 / 290 / x / -2 : h'30a0424cd21c2944838a2d75c92b37e76ea20d9f008 291 93a3b4eee8a3c0aaf', 292 / y / -3 : h'e04b65e92456d9888b52b379bdfbd51ee869ef1f0fc 293 65b6659695b6cce08' 294 } 295 } 296 ] 297 } 298 } 299 Figure 3: Example Attestation Verification Claim 301 3.4. Certification Claims 303 PSA Certified [PSA-CERTIFIED] defines a certification scheme for the 304 PSA ecosystem. A product - either a hardware component, a software 305 component, or an entire device - that is verified to meet the 306 security criteria established by the PSA Certified scheme is 307 warranted a PSA Certified Security Assurance Certificate (SAC). A 308 SAC contains information about the certification of a certain product 309 (e.g., the target system, the attained certification level, the test 310 lab that conducted the evaluation, etc.), and has a unique 311 Certificate Number. 313 The linkage between a PSA RoT and a related SAC is provided by a 314 Certification Claim, which binds the PSA RoT Implementation ID with 315 the SAC unique Certificate Number. When appraising Evidence, the 316 Verifier can use the Certification Claims associated with the 317 identified Attester as ancillary input to the Appraisal Policy, or to 318 enrich the produced Attestation Result. 320 A Certification Claim is encoded in an "psa-cert-triple-record", 321 which extends the "$$triples-map-extension" socket, as follows: 323 comid.psa-cert-triples = 4 325 $$triples-map-extension //= ( 326 comid.psa-cert-triples => one-or-more 327 ) 329 psa-cert-triple-record = [ 330 tagged-impl-id-type, 331 psa-cert-num-type 332 ] 334 psa-cert-num-type = text .regexp "[0-9]{13} - [0-9]{5}" 336 * The Implementation ID to which the SAC applies is encoded in the 337 "tagged-impl-id-type"; 339 * The unique SAC Certificate Number is encoded in the "psa-cert-num- 340 type". 342 A single CoMID can carry one or more Certification Claims. 344 The example in Figure 4 shows a Certification Claim for Certificate 345 Number "1234567890123 - 12345" and Implementation ID "acme- 346 implementation-id-000000001". 348 / concise-mid-tag / { 349 / comid.tag-identity / 1 : { 350 / comid.tag-id / 0 : h'3f06af63a93c11e4979700505690773f' 351 }, 352 / comid.triples / 4 : { 353 / comid.psa-cert-triples / 4 : [ 354 / tagged-impl-id-type / 47115( 355 h'61636d652d696d706c656d656e746174696f6e2d69642d303030303030 356 303031' 357 ), 358 / psa-cert-num-type / "1234567890123 - 12345" 359 ] 360 } 361 } 363 Figure 4: Example Certification Claim with `supplement` Link-Relation 365 3.5. Endorsements Block List 367 The following three "blocklist" claims: 369 * "reference-blocklist-triple" 371 * "attest-key-blocklist-triple" 373 * "cert-blocklist-triple" 375 are defined with the same syntax but opposite semantics with regards 376 to their "positive" counterparts to allow invalidating previously 377 provisioned endorsements from the acceptable set. 379 4. Security Considerations 381 TODO 383 5. IANA Considerations 385 TODO 387 Acknowledgements 389 TODO 391 References 393 Normative References 395 [CoRIM] Birkholz, H., Fossati, T., Deshpande, Y., Smith, N., and 396 W. Pan, "Concise Reference Integrity Manifest", Work in 397 Progress, Internet-Draft, draft-birkholz-rats-corim-00, 12 398 July 2021, . 401 [PSA-TOKEN] 402 Tschofenig, H., Frost, S., Brossard, M., Shaw, A., and T. 403 Fossati, "Arm's Platform Security Architecture (PSA) 404 Attestation Token", Work in Progress, Internet-Draft, 405 draft-tschofenig-rats-psa-token-08, 24 March 2021, 406 . 409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels", BCP 14, RFC 2119, 411 DOI 10.17487/RFC2119, March 1997, 412 . 414 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 415 RFC 8152, DOI 10.17487/RFC8152, July 2017, 416 . 418 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 419 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 420 May 2017, . 422 Informative References 424 [PSA-CERTIFIED] 425 "PSA Certified", 2021, . 427 [RATS-ARCH] 428 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 429 W. Pan, "Remote Attestation Procedures Architecture", Work 430 in Progress, Internet-Draft, draft-ietf-rats-architecture- 431 12, 23 April 2021, . 434 Authors' Addresses 436 Thomas Fossati 437 Arm Ltd 439 Email: thomas.fossati@arm.com 440 Yogesh Deshpande 441 Arm Ltd 443 Email: yogesh.deshpande@arm.com 445 Henk Birkholz 446 Fraunhofer SIT 448 Email: henk.birkholz@sit.fraunhofer.de