idnits 2.17.1 draft-fdb-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 (8 November 2021) is 901 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-01 == Outdated reference: A later version (-22) exists of draft-tschofenig-rats-psa-token-08 == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-12 Summary: 0 errors (**), 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: 12 May 2022 H. Birkholz 6 Fraunhofer SIT 7 8 November 2021 9 Arm's Platform Security Architecture (PSA) Attestation Verifier 10 Endorsements 11 draft-fdb-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 12 May 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 Endorsement Profile . . . . . . . . . . . . . . . . . 3 57 3.2. PSA Endorsements to PSA RoT Linkage . . . . . . . . . . . 4 58 3.3. Reference Values . . . . . . . . . . . . . . . . . . . . 5 59 3.3.1. Software Upgrades and Patches . . . . . . . . . . . . 8 60 3.4. Attestation Verification Claims . . . . . . . . . . . . . 10 61 3.5. Certification Claims . . . . . . . . . . . . . . . . . . 12 62 3.6. Endorsements Block List . . . . . . . . . . . . . . . . . 14 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 65 5.1. CBOR Tag Registrations . . . . . . . . . . . . . . . . . 14 66 5.2. CoRIM Profile Registration . . . . . . . . . . . . . . . 14 67 5.3. CoMID Codepoints . . . . . . . . . . . . . . . . . . . . 15 68 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15 69 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 Normative References . . . . . . . . . . . . . . . . . . . . . 15 71 Informative References . . . . . . . . . . . . . . . . . . . . 16 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 74 1. Introduction 76 PSA Endorsements include reference values, cryptographic key material 77 and certification status information that a Verifier needs in order 78 to appraise attestation Evidence produced by a PSA device 79 [PSA-TOKEN]. This memo defines such PSA Endorsements as a profile of 80 the CoRIM data model [CoRIM]. 82 2. Conventions and Definitions 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 86 "OPTIONAL" in this document are to be interpreted as described in 87 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 88 capitals, as shown here. 90 The reader is assumed to be familiar with the terms defined in 91 Section 2.1 of [PSA-TOKEN] and in Section 4 of [RATS-ARCH]. 93 3. PSA Endorsements 95 PSA Endorsements describe an attesting device in terms of the 96 hardware and firmware components that make up its PSA Root of Trust 97 (RoT). This includes the identification and expected state of the 98 device as well as the cryptographic key material needed to verify 99 Evidence signed by the device's PSA RoT. Additionally, PSA 100 Endorsements can include information related to the certification 101 status of the attesting device. 103 There are five types of PSA Endorsements: 105 * Reference Values (Section 3.3), i.e., measurements of the PSA RoT 106 firmware; 108 * Attestation Verification Claims (Section 3.4), i.e., cryptographic 109 keys that can be used to verify signed Evidence produced by the 110 PSA RoT, along with the identifiers that bind the keys to their 111 device instances; 113 * Certification Claims (Section 3.5), i.e., metadata that describe 114 the certification status associated with a PSA device. 116 * Software Relations (Section 3.3.1), used to model upgrade and 117 patch relationships between software components; 119 * Endorsements Block List (Section 3.6), used to invalidate 120 previously provisioned Endorsements. 122 3.1. PSA Endorsement Profile 124 PSA Endorsements are carried in one or more CoMIDs inside a CoRIM. 126 The profile attribute in the CoRIM MUST be present and MUST have a 127 single entry set to the uri http://arm.com/psa/iot/1 as shown in 128 Figure 1. 130 / corim-map / { 131 / corim.profile / 3: [ 132 32("http://arm.com/psa/iot/1") 133 ] 134 / ... / 135 } 137 Figure 1: PSA IoT version 1, CoRIM profile 139 3.2. PSA Endorsements to PSA RoT Linkage 141 Each PSA Endorsement - be it a Reference Value, Attestation 142 Verification Claim or Certification Claim - is associated with an 143 immutable PSA RoT. A PSA Endorsement is associated to its PSA RoT by 144 means of the unique PSA RoT identifier known as Implementation ID 145 (see Section 3.2.2 of [PSA-TOKEN]). 147 In order to support PSA Implementation IDs, the CoMID type $class-id- 148 type-choice is extended as follows: 150 ; from draft-tschofenig-rats-psa-token 151 psa-implementation-id-type = bytes .size 32 153 tagged-implementation-id-type = #6.600(implementation-id-type) 155 $class-id-type-choice /= tagged-implementation-id-type 157 Besides, a PSA Endorsement can be associated with a specific instance 158 of a certain PSA RoT - as in the case of Attestation Verification 159 Claims. A PSA Endorsement is associated with a PSA RoT instance by 160 means of the Instance ID (see Section 3.2.1 of [PSA-TOKEN]) and its 161 "parent" Implementation ID. 163 These identifiers are typically found in the subject of a CoMID 164 triple, encoded in an environment-map as shown in Figure 2. 166 / environment-map / { 167 / comid.class / 0 : { 168 / comid.class-id / 0 : 169 / tagged-impl-id-type / 600( 170 h'61636d652d696d706c656d656e746174 171 696f6e2d69642d303030303030303031' 172 ), 173 / comid.vendor / 1 : "ACME Ltd.", 174 / comid.model / 2 : "Roadrunner 1.0" 175 }, 176 / comid.instance / 1 : 177 / tagged-ueid-type / 550( 178 h'01 179 4ca3e4f50bf248c39787020d68ffd05c 180 88767751bf2645ca923f57a98becd296' 181 ) 182 } 184 Figure 2: Example PSA RoT Identification 186 Optional vendor and model can be specified as well. Together, they 187 are interpreted as a unique identifier of the product that embeds the 188 PSA RoT. Consistently providing a product identifier is RECOMMENDED. 190 3.3. Reference Values 192 Reference Values carry measurements and other metadata associated 193 with the updatable firmware in a PSA RoT. When appraising Evidence, 194 the Verifier compares Reference Values against the values found in 195 the Software Components of the PSA token (see Section 3.4.1 of 196 [PSA-TOKEN]). 198 Each measurement is encoded in a measurement-map of a CoMID 199 reference-triple-record. Since a measurement-map can encode one or 200 more measurements, a single reference-triple-record can carry as many 201 measurements as needed, provided they belong to the same PSA RoT 202 identified in the subject of the "reference value" triple. A single 203 reference-triple-record SHALL completely describe the updatable PSA 204 RoT. 206 The identifier of a measured software component is encoded in a psa- 207 swcomp-id object as follows: 209 psa-swcomp-id = { 210 psa.measurement-type => text 211 psa.version => text 212 psa.signer-id => psa.hash-type 213 } 215 psa.hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64 217 psa.measurement-type = 1 218 psa.version = 4 219 psa.signer-id = 5 221 The semantics of the codepoints in the psa-swcomp-id map are 222 equivalent to those in the psa-software-component map defined in 223 Section 3.4.1 of [PSA-TOKEN]. The psa-swcomp-id MUST uniquely 224 identify a given software component within the PSA RoT / product. 226 In order to support PSA Reference Value identifiers, the CoMID type 227 $measured-element-type-choice is extended as follows: 229 tagged-psa-swcomp-id = #6.601(psa-swcomp-id) 231 $measured-element-type-choice /= tagged-psa-swcomp-id 233 and automatically bound to the comid.mkey in the measurement-map. 235 The raw measurement is encoded in a digests-type object in the 236 measurement-values-map. The digests-type array MUST contain at least 237 one entry. The digests-type array MAY contain more than one entry if 238 multiple digests (obtained with different hash algorithms) of the 239 same measured component exist. 241 The example in Figure 3 shows a CoMID a PSA Endorsement of type 242 Reference Value for a firmware measurement associated with 243 Implementation ID acme-implementation-id-000000001. 245 / concise-mid-tag / { 246 / comid.tag-identity / 1 : { 247 / comid.tag-id / 0 : h'3f06af63a93c11e4979700505690773f' 248 }, 249 / comid.triples / 4 : { 250 / comid.reference-triples / 0 : [ 251 [ 252 / environment-map / { 253 / comid.class / 0 : { 254 / comid.class-id / 0 : 255 / tagged-impl-id-type / 600( 256 h'61636d652d696d706c656d656e746174 257 696f6e2d69642d303030303030303031' 258 ), 259 / comid.vendor / 1 : "ACME Ltd.", 260 / comid.model / 2 : "Roadrunner 1.0" 261 } 262 }, 263 / measurement-map / { 264 / comid.mkey / 0 : 601({ 265 / psa.measurement-type / 1 : "PRoT", 266 / psa.version / 4 : "1.3.5", 267 / psa.signer-id / 5 : h'acbb11c7e4da2172 268 05523ce4ce1a245a 269 e1a239ae3c6bfd9e 270 7871f7e5d8bae86b' 271 }), 272 / comid.mval / 1 : { 273 / comid.digests / 2 : [ 274 / hash-alg-id / 1, / sha256 / 275 / hash-value / h'44aa336af4cb14a8 276 79432e53dd6571c7 277 fa9bccafb75f4882 278 59262d6ea3a4d91b' 279 ] 280 } 281 } 282 ] 283 ] 284 } 285 } 287 Figure 3: Example Reference Value 289 3.3.1. Software Upgrades and Patches 291 In order to model software lifecycle events such as updates and 292 patches, this profile defines a new triple that conveys the following 293 semantics: 295 * SUBJECT: a software component 297 * PREDICATE: (non-critically / critically) (updates / patches) 299 * OBJECT: another software component 301 The triple is reified and used as the object of another triple, psa- 302 swrel-triple-record, whose subject is the embedding environment. 304 comid.psa-swrel-triples = 5 306 $$triples-map-extension //= ( 307 comid.psa-swrel-triples => [ + psa-swrel-triple-record ] 308 ) 310 psa.updates = 1 311 psa.patches = 2 313 psa-swrel-rel = [ 314 type: psa.updates / psa.patches 315 security-critical: bool ; true means it's a fix for a security bug 316 ] 318 sw-rel = [ 319 new: psa-swcomp-id ; identifier of the "new" firmware 320 rel: psa-swrel-rel ; patches, updates and the security flag 321 old: psa-swcomp-id ; identifier of the "old" firmware 322 ] 324 psa-swrel-triple-record = [ 325 environment-map 326 sw-rel 327 ] 329 An example of a security critical update involving versions "1.3.5" 330 and "1.4.0" of software component "PRoT" within the target 331 environment associated with Implementation ID acme-implementation- 332 id-000000001 is shown in Figure 4. 334 / concise-mid-tag / { 335 / comid.tag-identity / 1 : { 336 / comid.tag-id / 0 : h'3f06af63a93c11e4979700505690773f' 337 }, 338 / comid.triples / 4 : { 339 / comid.psa-swrel-triples / 5 : [ 340 [ 341 / environment-map / { 342 / comid.class-id / 0 : 343 / tagged-impl-id-type / 600( 344 h'61636d652d696d706c656d656e746174 345 696f6e2d69642d303030303030303031' 346 ), 347 / comid.vendor / 1 : "ACME Ltd.", 348 / comid.model / 2 : "Roadrunner 1.0" 349 }, 351 / sw-rel / [ 352 / new / { 353 / psa.measurement-type / 1 : "PRoT", 354 / psa.version / 4 : "1.4.0", 355 / psa.signer-id / 5 : h'acbb11c7e4da2172 356 05523ce4ce1a245a 357 e1a239ae3c6bfd9e 358 7871f7e5d8bae86b' 359 }, 361 / rel / [ 362 / type / 1, / psa.updates / 363 / security-critical / true 364 ], 366 / old / { 367 / psa.measurement-type / 1 : "PRoT", 368 / psa.version / 4 : "1.3.5", 369 / psa.signer-id / 5 : h'acbb11c7e4da2172 370 05523ce4ce1a245a 371 e1a239ae3c6bfd9e 372 7871f7e5d8bae86b' 373 } 374 ] 375 ] 376 ] 377 } 378 } 380 Figure 4: Example Critical Software Upgrade 382 3.4. Attestation Verification Claims 384 An Attestation Verification Claim carries the verification key 385 associated with the Initial Attestation Key (IAK) of a PSA device. 386 When appraising Evidence, the Verifier uses the Implementation ID and 387 Instance ID claims (see Section 3.2) to retrieve the verification key 388 that it SHALL use to check the signature on the Evidence. This 389 allows the Verifier to prove (or disprove) the Attester's claimed 390 identity. 392 Each verification key is provided alongside the corresponding device 393 Instance and Implementation IDs (and, possibly, a product identifier) 394 in an attest-key-triple-record. Specifically: 396 * The Instance and Implementation IDs are encoded in the 397 environment-map as shown in Figure 2; 399 * The IAK public key is carried in the comid.key entry in the 400 verification-key-map. The IAK public key is a PEM-encoded 401 SubjectPublicKeyInfo [RFC5280]. There MUST be only one 402 verification-key-map in an attest-key-triple-record; 404 * The optional comid.keychain entry MUST NOT be set by a CoMID 405 producer that uses the profile described in this document, and 406 MUST be ignored by a CoMID consumer that is parsing according to 407 this profile. 409 The example in Figure 5 shows the PSA Endorsement of type Attestation 410 Verification Claim carrying a secp256r1 EC public IAK associated with 411 Instance ID 4ca3...d296. 413 / concise-mid-tag / { 414 / comid.tag-identity / 1 : { 415 / comid.tag-id / 0 : h'3f06af63a93c11e4979700505690773f' 416 }, 417 / comid.triples / 4 : { 418 / comid.attest-key-triples / 3 : [ 419 [ 420 / environment-map / { 421 / comid.class / 0 : { 422 / comid.class-id / 0 : 423 / tagged-impl-id-type / 600( 424 h'61636d652d696d706c656d656e746174 425 696f6e2d69642d303030303030303031' 426 ), 427 / comid.vendor / 1 : "ACME Ltd.", 428 / comid.model / 2 : "Roadrunner 1.0" 429 }, 430 / comid.instance / 1 : 431 / tagged-ueid-type / 550( 432 h'01 433 4ca3e4f50bf248c39787020d68ffd05c 434 88767751bf2645ca923f57a98becd296' 435 ) 436 }, 437 / verification-key-map / { 438 / comid.key / 0 : 439 "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgA 440 ETl4iCZ47zrRbRG0TVf0dw7VFlHtv18HInY 441 hnmMNybo+A1wuECyVqrDSmLt4QQzZPBECV8 442 ANHS5HgGCCSr7E/Lg==" 443 } 444 ] 445 ] 446 } 447 } 449 Figure 5: Example Attestation Verification Claim 451 3.5. Certification Claims 453 PSA Certified [PSA-CERTIFIED] defines a certification scheme for the 454 PSA ecosystem. A product - either a hardware component, a software 455 component, or an entire device - that is verified to meet the 456 security criteria established by the PSA Certified scheme is 457 warranted a PSA Certified Security Assurance Certificate (SAC). A 458 SAC contains information about the certification of a certain product 459 (e.g., the target system, the attained certification level, the test 460 lab that conducted the evaluation, etc.), and has a unique 461 Certificate Number. 463 The linkage between a PSA RoT -- comprising the immutable part as 464 well as zero or more of the mutable components -- and the associated 465 SAC is provided by a Certification Claim, which binds the PSA RoT 466 Implementation ID and the software component identifiers with the SAC 467 unique Certificate Number. When appraising Evidence, the Verifier 468 can use the Certification Claims associated with the identified 469 Attester as ancillary input to the Appraisal Policy, or to enrich the 470 produced Attestation Result. 472 A Certification Claim is encoded in an psa-cert-triple-record, which 473 extends the $$triples-map-extension socket, as follows: 475 comid.psa-cert-triples = 4 477 $$triples-map-extension //= ( 478 comid.psa-cert-triples => [ + psa-cert-triple-record ] 479 ) 481 psa.immutable-rot = 1 482 psa.mutable-rot = 2 484 psa-rot-descriptor = { 485 psa.immutable-rot => psa-implementation-id-type 486 psa.mutable-rot => [ * psa-swcomp-id ] 487 } 489 psa-cert-triple-record = [ 490 psa-rot-descriptor 491 psa-cert-num-type 492 ] 494 psa-cert-num-type = text .regexp "[0-9]{13} - [0-9]{5}" 496 * The Implementation ID of the immutable PSA RoT to which the SAC 497 applies is encoded as a tagged-impl-id-type in the psa.immutable- 498 rot of the psa-rot-descriptor; 500 * Any software component that is part of the certified PSA RoT is 501 encoded as a psa-swcomp-id (see Section 3.3) in the psa.mutable- 502 rot of the psa-rot-descriptor; 504 * The unique SAC Certificate Number is encoded in the psa-cert-num- 505 type. 507 A single CoMID can carry one or more Certification Claims. 509 The example in Figure 6 shows a Certification Claim that associates 510 Certificate Number 1234567890123 - 12345 to Implementation ID acme- 511 implementation-id-000000001 and a single "PRoT" software component 512 with version "1.3.5". 514 / concise-mid-tag / { 515 / comid.tag-identity / 1 : { 516 / comid.tag-id / 0 : h'3f06af63a93c11e4979700505690773f' 517 }, 518 / comid.triples / 4 : { 519 / comid.psa-cert-triples / 4 : [ 520 [ 521 / psa-rot-descriptor / { 522 / psa.immutable-rot / 1 : 523 h'61636d652d696d706c656d656e746174 524 696f6e2d69642d303030303030303031', 525 / psa.mutable-rot / 2 : [ 526 / psa-swcomp-id / { 527 / psa.measurement-type / 1 : "PRoT", 528 / psa.version / 4 : "1.3.5", 529 / psa.signer-id / 5 : h'acbb11c7e4da2172 530 05523ce4ce1a245a 531 e1a239ae3c6bfd9e 532 7871f7e5d8bae86b' 533 } 534 ] 535 }, 536 / psa-cert-num-type / "1234567890123 - 12345" 537 ] 538 ] 539 } 540 } 542 Figure 6: Example Certification Claim with `supplement` Link-Relation 544 3.6. Endorsements Block List 546 // This is work in progress. It may change or be removed in the 547 // future. 549 The following three "blocklist" claims: 551 * reference-blocklist-triple 553 * attest-key-blocklist-triple 555 * cert-blocklist-triple 557 are defined with the same syntax but opposite semantics with regards 558 to their "positive" counterparts to allow invalidating previously 559 provisioned endorsements from the acceptable set. 561 4. Security Considerations 563 // TODO 565 5. IANA Considerations 567 5.1. CBOR Tag Registrations 569 IANA is requested to allocate the following tag in the "CBOR Tags" 570 registry [IANA.cbor-tags], preferably with the specified value: 572 +=====+==============+===================================+ 573 | Tag | Data Item | Semantics | 574 +=====+==============+===================================+ 575 | 600 | tagged bytes | PSA Implementation ID | 576 | | | (Section 3.2 of RFCTHIS) | 577 +-----+--------------+-----------------------------------+ 578 | 601 | tagged map | PSA Software Component Identifier | 579 | | | (Section 3.3 of RFCTHIS) | 580 +-----+--------------+-----------------------------------+ 582 Table 1: CoRIM CBOR Tags 584 5.2. CoRIM Profile Registration 586 IANA is requested to register the following profile value in the 587 // TODO 588 +==========================+======+============================+ 589 | Profile Value | Type | Semantics | 590 +==========================+======+============================+ 591 | http://arm.com/psa/iot/1 | uri | The CoRIM profile | 592 | | | specified by this document | 593 +--------------------------+------+----------------------------+ 595 Table 2: PSA profile for CoRIM 597 5.3. CoMID Codepoints 599 IANA is requested to register the following codepoints to the "CoMID 600 Triples Map" registry. 602 +=======+=========================+===============+ 603 | Index | Item Name | Specification | 604 +=======+=========================+===============+ 605 | 4 | comid.psa-cert-triples | RFCTHIS | 606 +-------+-------------------------+---------------+ 607 | 5 | comid.psa-swrel-triples | RFCTHIS | 608 +-------+-------------------------+---------------+ 610 Table 3: PSA CoMID Triples 612 Acknowledgements 614 // TODO 616 References 618 Normative References 620 [CoRIM] Birkholz, H., Fossati, T., Deshpande, Y., Smith, N., and 621 W. Pan, "Concise Reference Integrity Manifest", Work in 622 Progress, Internet-Draft, draft-birkholz-rats-corim-01, 26 623 July 2021, . 626 [IANA.cbor-tags] 627 IANA, "Concise Binary Object Representation (CBOR) Tags", 628 . 630 [PSA-TOKEN] 631 Tschofenig, H., Frost, S., Brossard, M., Shaw, A., and T. 632 Fossati, "Arm's Platform Security Architecture (PSA) 633 Attestation Token", Work in Progress, Internet-Draft, 634 draft-tschofenig-rats-psa-token-08, 24 March 2021, 635 . 638 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 639 Requirement Levels", BCP 14, RFC 2119, 640 DOI 10.17487/RFC2119, March 1997, 641 . 643 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 644 Housley, R., and W. Polk, "Internet X.509 Public Key 645 Infrastructure Certificate and Certificate Revocation List 646 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 647 . 649 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 650 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 651 May 2017, . 653 Informative References 655 [PSA-CERTIFIED] 656 "PSA Certified", 2021, . 658 [RATS-ARCH] 659 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 660 W. Pan, "Remote Attestation Procedures Architecture", Work 661 in Progress, Internet-Draft, draft-ietf-rats-architecture- 662 12, 23 April 2021, . 665 Authors' Addresses 667 Thomas Fossati 668 Arm Ltd 670 Email: thomas.fossati@arm.com 672 Yogesh Deshpande 673 Arm Ltd 675 Email: yogesh.deshpande@arm.com 676 Henk Birkholz 677 Fraunhofer SIT 679 Email: henk.birkholz@sit.fraunhofer.de