idnits 2.17.1 draft-ietf-teep-protocol-04.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 (November 2, 2020) is 1269 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CDDL' is mentioned on line 635, but not defined == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-04 == Outdated reference: A later version (-01) exists of draft-moran-suit-report-00 ** Downref: Normative reference to an Informational draft: draft-moran-suit-report (ref. 'I-D.moran-suit-report') ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-24) exists of draft-ietf-sacm-coswid-15 == Outdated reference: A later version (-19) exists of draft-ietf-teep-architecture-12 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEEP H. Tschofenig 3 Internet-Draft Arm Ltd. 4 Intended status: Standards Track M. Pei 5 Expires: May 6, 2021 Broadcom 6 D. Wheeler 7 Intel 8 D. Thaler 9 Microsoft 10 A. Tsukamoto 11 AIST 12 November 2, 2020 14 Trusted Execution Environment Provisioning (TEEP) Protocol 15 draft-ietf-teep-protocol-04 17 Abstract 19 This document specifies a protocol that installs, updates, and 20 deletes Trusted Applications (TAs) in a device with a Trusted 21 Execution Environment (TEE). This specification defines an 22 interoperable protocol for managing the lifecycle of TAs. 24 The protocol name is pronounced teepee. This conjures an image of a 25 wedge-shaped protective covering for one's belongings, which sort of 26 matches the intent of this protocol. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 6, 2021. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Message Overview . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Detailed Messages Specification . . . . . . . . . . . . . . . 6 66 4.1. Creating and Validating TEEP Messages . . . . . . . . . . 6 67 4.1.1. Creating a TEEP message . . . . . . . . . . . . . . . 6 68 4.1.2. Validating a TEEP Message . . . . . . . . . . . . . . 6 69 4.2. QueryRequest Message . . . . . . . . . . . . . . . . . . 7 70 4.3. QueryResponse Message . . . . . . . . . . . . . . . . . . 9 71 4.4. Install Message . . . . . . . . . . . . . . . . . . . . . 12 72 4.5. Delete Message . . . . . . . . . . . . . . . . . . . . . 13 73 4.6. Success Message . . . . . . . . . . . . . . . . . . . . . 14 74 4.7. Error Message . . . . . . . . . . . . . . . . . . . . . . 14 75 5. Mapping of TEEP Message Parameters to CBOR Labels . . . . . . 17 76 6. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 17 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 79 8.1. Media Type Registration . . . . . . . . . . . . . . . . . 20 80 8.2. Error Code Registry . . . . . . . . . . . . . . . . . . . 21 81 8.3. Ciphersuite Registry . . . . . . . . . . . . . . . . . . 21 82 8.4. CBOR Tag Registry . . . . . . . . . . . . . . . . . . . . 21 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 85 9.2. Informative References . . . . . . . . . . . . . . . . . 23 86 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24 87 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 88 C. Complete CDDL . . . . . . . . . . . . . . . . . . . . . . . . 24 89 D. Examples of Diagnostic Notation and Binary Representation . . 27 90 D.1. Some assumptions in examples . . . . . . . . . . . . . . 27 91 D.2. QueryRequest Message . . . . . . . . . . . . . . . . . . 28 92 D.2.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 28 93 D.2.2. CBOR Binary Representation . . . . . . . . . . . . . 28 94 D.3. QueryResponse Message . . . . . . . . . . . . . . . . . . 29 95 D.3.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 29 96 D.3.2. CBOR Binary Representation . . . . . . . . . . . . . 29 97 D.4. Install Message . . . . . . . . . . . . . . . . . . . . . 29 98 D.4.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 29 99 D.4.2. CBOR Binary Representation . . . . . . . . . . . . . 30 100 D.5. Success Message (for Install) . . . . . . . . . . . . . . 30 101 D.5.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 30 102 D.5.2. CBOR Binary Representation . . . . . . . . . . . . . 30 103 D.6. Error Message (for Install) . . . . . . . . . . . . . . . 30 104 D.6.1. CBOR Diagnostic Notation . . . . . . . . . . . . . . 30 105 D.6.2. CBOR binary Representation . . . . . . . . . . . . . 31 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 108 1. Introduction 110 The Trusted Execution Environment (TEE) concept has been designed to 111 separate a regular operating system, also referred as a Rich 112 Execution Environment (REE), from security-sensitive applications. 113 In a TEE ecosystem, device vendors may use different operating 114 systems in the REE and may use different types of TEEs. When TA 115 Developers or Device Administrators use Trusted Application Managers 116 (TAMs) to install, update, and delete Trusted Applications (TAs) on a 117 wide range of devices with potentially different TEEs then an 118 interoperability need arises. 120 This document specifies the protocol for communicating between a TAM 121 and a TEEP Agent. 123 The Trusted Execution Environment Provisioning (TEEP) architecture 124 document [I-D.ietf-teep-architecture] provides design guidance and 125 introduces the necessary terminology. 127 2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in 132 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 133 capitals, as shown here. 135 This specification re-uses the terminology defined in 136 [I-D.ietf-teep-architecture]. 138 As explained in Section 4.4 of that document, the TEEP protocol 139 treats each TA, any dependencies the TA has, and personalization data 140 as separate components that are expressed in SUIT manifests, and a 141 SUIT manifest might contain or reference multiple binaries (see 142 [I-D.ietf-suit-manifest] for more details). 144 As such, the term Trusted Component in this document refers to a set 145 of binaries expressed in a SUIT manifest, to be installed in a TEE. 146 Note that a Trusted Component may include one or more TAs and/or 147 configuration data and keys needed by a TA to operate correctly. 149 Each Trusted Component is uniquely identified by a "component-id" 150 byte string, such as a 16-byte UUID [RFC4122]. If Concise Software 151 Identifiers [I-D.ietf-sacm-coswid] are used (e.g., in the suit-coswid 152 field of SUIT manifests), the component-id value is the CoSWID tag-id 153 value. 155 3. Message Overview 157 The TEEP protocol consists of messages exchanged between a TAM and a 158 TEEP Agent. The messages are encoded in CBOR and designed to provide 159 end-to-end security. TEEP protocol messages are signed by the 160 endpoints, i.e., the TAM and the TEEP Agent, but Trusted Applications 161 may also be encrypted and signed by a TA Developer or Device 162 Administrator. The TEEP protocol not only uses CBOR but also the 163 respective security wrapper, namely COSE [RFC8152]. Furthermore, for 164 software updates the SUIT manifest format [I-D.ietf-suit-manifest] is 165 used, and for attestation the Entity Attestation Token (EAT) 166 [I-D.ietf-rats-eat] format is supported although other attestation 167 formats are also permitted. 169 This specification defines six messages. 171 A TAM queries a device's current state with a QueryRequest message. 172 A TEEP Agent will, after authenticating and authorizing the request, 173 report attestation information, list all Trusted Components, and 174 provide information about supported algorithms and extensions in a 175 QueryResponse message. An error message is returned if the request 176 could not be processed. A TAM will process the QueryResponse message 177 and determine whether to initiate subsequent message exchanges to 178 install, update, or delete Trusted Applications. 180 +------------+ +-------------+ 181 | TAM | |TEEP Agent | 182 +------------+ +-------------+ 184 QueryRequest -------> 186 QueryResponse 188 <------- or 190 Error 192 With the Install message a TAM can instruct a TEEP Agent to install a 193 Trusted Component. The TEEP Agent will process the message, 194 determine whether the TAM is authorized and whether the Trusted 195 Component has been signed by an authorized TA Signer. If the Install 196 message was processed successfully then a Success message is returned 197 to the TAM, or an Error message otherwise. 199 +------------+ +-------------+ 200 | TAM | |TEEP Agent | 201 +------------+ +-------------+ 203 Install ----> 205 Success 207 <---- or 209 Error 211 With the Delete message a TAM can instruct a TEEP Agent to delete one 212 or multiple Trusted Components. A Success message is returned when 213 the operation has been completed successfully, or an Error message 214 otherwise. 216 +------------+ +-------------+ 217 | TAM | |TEEP Agent | 218 +------------+ +-------------+ 220 Delete ----> 222 Success 224 <---- or 226 Error 228 4. Detailed Messages Specification 230 TEEP messages are protected by the COSE_Sign1 structure. The TEEP 231 protocol messages are described in CDDL format [RFC8610] below. 233 { 234 teep-message => (query-request / 235 query-response / 236 install / 237 delete / 238 teep-success / 239 teep-error ), 240 } 242 4.1. Creating and Validating TEEP Messages 244 4.1.1. Creating a TEEP message 246 To create a TEEP message, the following steps are performed. 248 1. Create a TEEP message according to the description below and 249 populate it with the respective content. 251 2. Create a COSE Header containing the desired set of Header 252 Parameters. The COSE Header MUST be valid per the [RFC8152] 253 specification. 255 3. Create a COSE_Sign1 object using the TEEP message as the 256 COSE_Sign1 Payload; all steps specified in [RFC8152] for creating 257 a COSE_Sign1 object MUST be followed. 259 4. Prepend the COSE object with the TEEP CBOR tag to indicate that 260 the CBOR-encoded message is indeed a TEEP message. 262 4.1.2. Validating a TEEP Message 264 When validating a TEEP message, the following steps are performed. 265 If any of the listed steps fail, then the TEEP message MUST be 266 rejected. 268 1. Verify that the received message is a valid CBOR object. 270 2. Remove the TEEP message CBOR tag and verify that one of the COSE 271 CBOR tags follows it. 273 3. Verify that the message contains a COSE_Sign1 structure. 275 4. Verify that the resulting COSE Header includes only parameters 276 and values whose syntax and semantics are both understood and 277 supported or that are specified as being ignored when not 278 understood. 280 5. Follow the steps specified in Section 4 of [RFC8152] ("Signing 281 Objects") for validating a COSE_Sign1 object. The COSE_Sign1 282 payload is the content of the TEEP message. 284 6. Verify that the TEEP message is a valid CBOR map and verify the 285 fields of the TEEP message according to this specification. 287 4.2. QueryRequest Message 289 A QueryRequest message is used by the TAM to learn information from 290 the TEEP Agent, such as the features supported by the TEEP Agent, 291 including ciphersuites, and protocol versions. Additionally, the TAM 292 can selectively request data items from the TEEP Agent via the 293 request parameter. Currently, the following features are supported: 295 o Request for attestation information, 297 o Listing supported extensions, 299 o Querying installed Trusted Components, and 301 o Listing supporting SUIT commands. 303 Like other TEEP messages, the QueryRequest message is signed, and the 304 relevant CDDL snippet is shown below. The complete CDDL structure is 305 shown in [CDDL]. 307 query-request = [ 308 type: TEEP-TYPE-query-request, 309 token: uint, 310 options: { 311 ? supported-cipher-suites => [ + suite ], 312 ? challenge => bstr .size (8..64), 313 ? versions => [ + version ], 314 ? ocsp-data => bstr, 315 * $$query-request-extensions 316 * $$teep-option-extensions 317 }, 318 data-item-requested 319 ] 321 The message has the following fields: 323 type 324 The value of (1) corresponds to a QueryRequest message sent from 325 the TAM to the TEEP Agent. 327 token 328 The value in the token parameter is used to match responses to 329 requests. This is particularly useful when a TAM issues multiple 330 concurrent requests to a TEEP Agent. 332 data-item-requested 333 The data-item-requested parameter indicates what information the 334 TAM requests from the TEEP Agent in the form of a bitmap. Each 335 value in the bitmap corresponds to an IANA registered information 336 element. This specification defines the following initial set of 337 information elements: 339 attestation (1) With this value the TAM requests the TEEP Agent 340 to return attestation evidence (e.g., an EAT) in the response. 342 trusted-components (2) With this value the TAM queries the TEEP 343 Agent for all installed Trusted Components. 345 extensions (4) With this value the TAM queries the TEEP Agent for 346 supported capabilities and extensions, which allows a TAM to 347 discover the capabilities of a TEEP Agent implementation. 349 suit-commands (8) With this value the TAM queries the TEEP Agent 350 for supported commands offered by the SUIT manifest 351 implementation. 353 Further values may be added in the future via IANA registration. 355 supported-cipher-suites 356 The supported-cipher-suites parameter lists the ciphersuite(s) 357 supported by the TAM. Details about the ciphersuite encoding can 358 be found in Section 6. 360 challenge 361 The challenge field is an optional parameter used for ensuring the 362 refreshness of the attestation evidence returned with a 363 QueryResponse message. When a challenge is provided in the 364 QueryRequest and an EAT is returned with the QueryResponse message 365 then the challenge contained in this request MUST be copied into 366 the nonce claim found in the EAT. If any format other than EAT is 367 used, it is up to that format to define the use of the challenge 368 field. 370 versions 371 The versions parameter enumerates the TEEP protocol version(s) 372 supported by the TAM A value of 0 refers to the current version of 373 the TEEP protocol. If this field is not present, it is to be 374 treated the same as if it contained only version 0. 376 ocsp-data 377 The ocsp-data parameter contains a list of OCSP stapling data 378 respectively for the TAM certificate and each of the CA 379 certificates up to the root certificate. The TAM provides OCSP 380 data so that the TEEP Agent can validate the status of the TAM 381 certificate chain without making its own external OCSP service 382 call. OCSP data MUST be conveyed as a DER-encoded OCSP response 383 (using the ASN.1 type OCSPResponse defined in [RFC2560]). The use 384 of OCSP is OPTIONAL to implement for both the TAM and the TEEP 385 Agent. A TAM can query the TEEP Agent for the support of this 386 functionality via the capability discovery exchange, as described 387 above. 389 4.3. QueryResponse Message 391 The QueryResponse message is the successful response by the TEEP 392 Agent after receiving a QueryRequest message. 394 Like other TEEP messages, the QueryResponse message is signed, and 395 the relevant CDDL snippet is shown below. The complete CDDL 396 structure is shown in [CDDL]. 398 query-response = [ 399 type: TEEP-TYPE-query-response, 400 token: uint, 401 options: { 402 ? selected-cipher-suite => suite, 403 ? selected-version => version, 404 ? evidence-format => text, 405 ? evidence => bstr, 406 ? tc-list => [ + tc-info ], 407 ? requested-ta-list => [ + requested-ta-info ], 408 ? unneeded-ta-list => [ + bstr ], 409 ? ext-list => [ + ext-info ], 410 * $$query-response-extensions, 411 * $$teep-option-extensions 412 } 413 ] 415 tc-info = { 416 component-id: bstr, 417 ? tc-manifest-sequence-number: uint 418 } 420 requested-ta-info = { 421 component-id: bstr, 422 ? tc-manifest-sequence-number: uint, 423 ? have-binary: bool 424 } 426 The QueryResponse message has the following fields: 428 type 429 The value of (2) corresponds to a QueryResponse message sent from 430 the TEEP Agent to the TAM. 432 token 433 The value in the token parameter is used to match responses to 434 requests. The value MUST correspond to the value received with 435 the QueryRequest message. 437 selected-cipher-suite 438 The selected-cipher-suite parameter indicates the selected 439 ciphersuite. Details about the ciphersuite encoding can be found 440 in Section 6. 442 selected-version 443 The selected-version parameter indicates the TEEP protocol version 444 selected by the TEEP Agent. The absense of this parameter 445 indicates the same as if it was present with a value of 0. 447 evidence-format 448 The evidence-format parameter indicates the IANA Media Type of the 449 attestation evidence contained in the evidence parameter. It MUST 450 be present if the evidence parameter is present and the format is 451 not an EAT. 453 evidence 454 The evidence parameter contains the attestation evidence. This 455 parameter MUST be present if the QueryResponse is sent in response 456 to a QueryRequest with the attestation bit set. If the evidence- 457 format parameter is absent, the attestation evidence contained in 458 this parameter MUST be an Entity Attestation Token following the 459 encoding defined in [I-D.ietf-rats-eat]. 461 tc-list 462 The tc-list parameter enumerates the Trusted Components installed 463 on the device in the form of tc-info objects. 465 requested-ta-list 466 The requested-ta-list parameter enumerates the Trusted 467 Applications that are not currently installed in the TEE, but 468 which are requested to be installed, for example by an installer 469 of an Untrusted Application that has a TA as a dependency. 470 Requested TAs are expressed in the form of requested-ta-info 471 objects. 473 unneeded-ta-list 474 The unneeded-ta-list parameter enumerates the Trusted Applications 475 that are currently installed in the TEE, but which are no longer 476 needed by any other application. The TAM can use this information 477 in determining whether a TA can be deleted. Each unneeded TA is 478 expressed in the form of a component-id byte string. 480 ext-list 481 The ext-list parameter lists the supported extensions. This 482 document does not define any extensions. 484 The tc-info object has the following fields: 486 component-id 487 A unique identifier encoded as a CBOR bstr. 489 tc-manifest-sequence-number 490 The suit-manifest-sequence-number value from the SUIT manifest for 491 the Trusted Component, if a SUIT manifest was used. 493 The requested-ta-info message has the following fields: 495 component-id 496 A unique identifier encoded as a CBOR bstr. 498 tc-manifest-sequence-number 499 The minimum suit-manifest-sequence-number value from a SUIT 500 manifest for the TA. If not present, indicates that any version 501 will do. 503 have-binary 504 If present with a value of true, indicates that the TEEP agent 505 already has the TA binary and only needs an Install message with a 506 SUIT manifest that authorizes installing it. If have-binary is 507 true, the tc-manifest-sequence-number field MUST be present. 509 4.4. Install Message 511 The Install message is used by the TAM to install a Trusted Component 512 via the TEEP Agent. 514 Like other TEEP messages, the Install message is signed, and the 515 relevant CDDL snippet is shown below. The complete CDDL structure is 516 shown in [CDDL]. 518 install = [ 519 type: TEEP-TYPE-install, 520 token: uint, 521 option: { 522 ? manifest-list => [ + SUIT_Envelope ], 523 * $$install-extensions, 524 * $$teep-option-extensions 525 } 526 ] 528 The Install message has the following fields: 530 type 531 The value of (3) corresponds to an Install message sent from the 532 TAM to the TEEP Agent. In case of successful processing, a 533 Success message is returned by the TEEP Agent. In case of an 534 error, an Error message is returned. Note that the Install 535 message is used for initial Trusted Component installation as well 536 as for updates. 538 token 539 The value in the token field is used to match responses to 540 requests. 542 manifest-list 543 The manifest-list field is used to convey one or multiple SUIT 544 manifests. A manifest is a bundle of metadata about a TA, such as 545 where to find the code, the devices to which it applies, and 546 cryptographic information protecting the manifest. The manifest 547 may also convey personalization data. TA binaries and 548 personalization data can be signed and encrypted by the same TA 549 Signer. Other combinations are, however, possible as well. For 550 example, it is also possible for the TAM to sign and encrypt the 551 personalization data and to let the TA Developer sign and/or 552 encrypt the TA binary. 554 4.5. Delete Message 556 The Delete message is used by the TAM to remove a Trusted Component 557 from the device. 559 Like other TEEP messages, the Delete message is signed, and the 560 relevant CDDL snippet is shown below. The complete CDDL structure is 561 shown in [CDDL]. 563 delete = [ 564 type: TEEP-TYPE-delete, 565 token: uint, 566 option: { 567 ? tc-list => [ + bstr ], 568 * $$delete-extensions, 569 * $$teep-option-extensions 570 } 571 ] 573 The Delete message has the following fields: 575 type 576 The value of (4) corresponds to a Delete message sent from the TAM 577 to the TEEP Agent. In case of successful processing, a Success 578 message is returned by the TEEP Agent. In case of an error, an 579 Error message is returned. 581 token 582 The value in the token parameter is used to match responses to 583 requests. 585 tc-list 586 The tc-list parameter enumerates the Trusted Components to be 587 deleted, in the form of component-id byte strings. 589 4.6. Success Message 591 The TEEP protocol defines two implicit success messages and this 592 explicit Success message for the cases where the TEEP Agent cannot 593 return another reply, such as for the Install and the Delete 594 messages. 596 Like other TEEP messages, the Success message is signed, and the 597 relevant CDDL snippet is shown below. The complete CDDL structure is 598 shown in [CDDL]. 600 teep-success = [ 601 type: TEEP-TYPE-teep-success, 602 token: uint, 603 option: { 604 ? msg => text, 605 ? suit-reports => [ + suit-report ], 606 * $$teep-success-extensions, 607 * $$teep-option-extensions 608 } 609 ] 611 The Success message has the following fields: 613 type 614 The value of (5) corresponds to corresponds to a Success message 615 sent from the TEEP Agent to the TAM. 617 token 618 The value in the token parameter is used to match responses to 619 requests. 621 msg 622 The msg parameter contains optional diagnostics information 623 encoded in UTF-8 [RFC3629] returned by the TEEP Agent. 625 suit-reports 626 If present, the suit-reports parameter contains a set of SUIT 627 Reports as defined in Section 4 of [I-D.moran-suit-report]. 629 4.7. Error Message 631 The Error message is used by the TEEP Agent to return an error. 633 Like other TEEP messages, the Error message is signed, and the 634 relevant CDDL snippet is shown below. The complete CDDL structure is 635 shown in [CDDL]. 637 teep-error = [ 638 type: TEEP-TYPE-teep-error, 639 token: uint, 640 err-code: uint, 641 options: { 642 ? err-msg => text, 643 ? supported-cipher-suites => [ + suite ], 644 ? versions => [ + version ], 645 ? suit-reports => [ + suit-report ], 646 * $$teep-error--extensions, 647 * $$teep-option-extensions 648 } 649 ] 651 The Error message has the following fields: 653 type 654 The value of (6) corresponds to an Error message sent from the 655 TEEP Agent to the TAM. 657 token 658 The value in the token parameter is used to match responses to 659 requests. 661 err-code 662 The err-code parameter contains one of the values listed in the 663 registry defined in Section 8.2 (with the initial set of error 664 codes listed below). Only selected values are applicable to each 665 message. 667 err-msg 668 The err-msg parameter is human-readable diagnostic text that MUST 669 be encoded using UTF-8 [RFC3629] using Net-Unicode form [RFC5198]. 671 supported-cipher-suites 672 The supported-cipher-suites parameter lists the ciphersuite(s) 673 supported by the TEEP Agent. Details about the ciphersuite 674 encoding can be found in Section 6. This field is optional but 675 MUST be returned with the ERR_UNSUPPORTED_CRYPTO_ALG error 676 message. 678 versions 679 The versions parameter enumerates the TEEP protocol version(s) 680 supported by the TEEP Agent. This otherwise optional parameter 681 MUST be returned with the ERR_UNSUPPORTED_MSG_VERSION error 682 message. 684 suit-reports 685 If present, the suit-reports parameter contains a set of SUIT 686 Reports as defined in Section 4 of [I-D.moran-suit-report]. 688 This specification defines the following initial error messages: 690 ERR_ILLEGAL_PARAMETER (1) 691 The TEEP request contained incorrect fields or fields that are 692 inconsistent with other fields. 694 ERR_UNSUPPORTED_EXTENSION (2) 695 The TEEP Agent does not support the request message or an 696 extension it indicated. 698 ERR_REQUEST_SIGNATURE_FAILED (3) 699 The TEEP Agent could not verify the signature of the request 700 message. 702 ERR_UNSUPPORTED_MSG_VERSION (4) 703 The TEEP Agent does not support the TEEP protocol version 704 indicated in the request message. 706 ERR_UNSUPPORTED_CRYPTO_ALG (5) 707 The TEEP Agent does not support the cryptographic algorithm 708 indicated in the request message. 710 ERR_BAD_CERTIFICATE (6) 711 Processing of a certificate failed. For diagnosis purposes it is 712 RECOMMMENDED to include information about the failing certificate 713 in the error message. 715 ERR_UNSUPPORTED_CERTIFICATE (7) 716 A certificate was of an unsupported type. 718 ERR_CERTIFICATE_REVOKED (8) 719 A certificate was revoked by its signer. 721 ERR_CERTIFICATE_EXPIRED (9) 722 A certificate has expired or is not currently valid. 724 ERR_INTERNAL_ERROR (10) 725 A miscellaneous internal error occurred while processing the 726 request message. 728 ERR_TC_NOT_FOUND (12) 729 The target Trusted Component does not exist. This error may 730 happen when the TAM has stale information and tries to delete a 731 Trusted Component that has already been deleted. 733 ERR_MANIFEST_PROCESSING_FAILED (17) 734 The TEEP Agent encountered one or more manifest processing 735 failures. If the suit-reports parameter is present, it contains 736 the failure details. 738 Additional error codes can be registered with IANA. 740 5. Mapping of TEEP Message Parameters to CBOR Labels 742 In COSE, arrays and maps use strings, negative integers, and unsigned 743 integers as their keys. Integers are used for compactness of 744 encoding. Since the word "key" is mainly used in its other meaning, 745 as a cryptographic key, this specification uses the term "label" for 746 this usage as a map key. 748 This specification uses the following mapping: 750 +-----------------------------+-------+ 751 | Name | Label | 752 +-----------------------------+-------+ 753 | supported-cipher-suites | 1 | 754 | challenge | 2 | 755 | version | 3 | 756 | ocsp-data | 4 | 757 | selected-cipher-suite | 5 | 758 | selected-version | 6 | 759 | evidence | 7 | 760 | tc-list | 8 | 761 | ext-list | 9 | 762 | manifest-list | 10 | 763 | msg | 11 | 764 | err-msg | 12 | 765 | evidence-format | 13 | 766 | requested-tc-list | 14 | 767 | unneeded-tc-list | 15 | 768 | component-id | 16 | 769 | tc-manifest-sequence-number | 17 | 770 | have-binary | 18 | 771 | suit-reports | 19 | 772 +-----------------------------+-------+ 774 6. Ciphersuites 776 A ciphersuite consists of an AEAD algorithm, an HMAC algorithm, and a 777 signature algorithm. Each ciphersuite is identified with an integer 778 value, which corresponds to an IANA registered ciphersuite (see 779 Section 8.3. This document specifies two ciphersuites. 781 +-------+------------------------------------------------+ 782 | Value | Ciphersuite | 783 +-------+------------------------------------------------+ 784 | 1 | AES-CCM-16-64-128, HMAC 256/256, X25519, EdDSA | 785 | 2 | AES-CCM-16-64-128, HMAC 256/256, P-256, ES256 | 786 +-------+------------------------------------------------+ 788 7. Security Considerations 790 This section summarizes the security considerations discussed in this 791 specification: 793 Cryptographic Algorithms 794 TEEP protocol messages exchanged between the TAM and the TEEP 795 Agent are protected using COSE. This specification relies on the 796 cryptographic algorithms provided by COSE. Public key based 797 authentication is used by the TEEP Agent to authenticate the TAM 798 and vice versa. 800 Attestation 801 A TAM can rely on the attestation evidence provided by the TEEP 802 Agent. To sign the attestation evidence, it is necessary for the 803 device to possess a public key (usually in the form of a 804 certificate) along with the corresponding private key. Depending 805 on the properties of the attestation mechanism, it is possible to 806 uniquely identify a device based on information in the attestation 807 evidence or in the certificate used to sign the attestation 808 evidence. This uniqueness may raise privacy concerns. To lower 809 the privacy implications the TEEP Agent MUST present its 810 attestation evidence only to an authenticated and authorized TAM 811 and when using EATS, it SHOULD use encryption as discussed in 812 [I-D.ietf-rats-eat], since confidentiality is not provided by the 813 TEEP protocol itself and the transport protocol under the TEEP 814 protocol might be implemented outside of any TEE. If any 815 mechanism other than EATs is used, it is up to that mechanism to 816 specify how privacy is provided. 818 TA Binaries 819 Each TA binary is signed by a TA Signer. It is the responsibility 820 of the TAM to relay only verified TAs from authorized TA Signers. 821 Delivery of a TA to the TEEP Agent is then the responsibility of 822 the TAM, using the security mechanisms provided by the TEEP 823 protocol. To protect the TA binary, the SUIT manifest format is 824 used and it offers a variety of security features, including 825 digitial signatures and symmetric encryption. 827 Personalization Data 828 A TA Signer or TAM can supply personalization data along with a 829 TA. This data is also protected by a SUIT manifest. 830 Personalization data signed and encrypted by a TA Signer other 831 than the TAM is opaque to the TAM. 833 TEEP Broker 834 As discussed in section 6 of [I-D.ietf-teep-architecture], the 835 TEEP protocol typically relies on a TEEP Broker to relay messages 836 between the TAM and the TEEP Agent. When the TEEP Broker is 837 compromised it can drop messages, delay the delivery of messages, 838 and replay messages but it cannot modify those messages. (A 839 replay would be, however, detected by the TEEP Agent.) A 840 compromised TEEP Broker could reorder messages in an attempt to 841 install an old version of a TA. Information in the manifest 842 ensures that TEEP Agents are protected against such downgrade 843 attacks based on features offered by the manifest itself. 845 TA Signer Compromise 846 The QueryRequest message from a TAM to the TEEP Agent can include 847 OCSP stapling data for the TAM's certificate and for intermediate 848 CA certificates up to the root certificate so that the TEEP Agent 849 can verify the certificate's revocation status. A certificate 850 revocation status check on a TA Signer certificate is OPTIONAL by 851 a TEEP Agent. A TAM is responsible for vetting a TA and before 852 distributing them to TEEP Agents, so TEEP Agents can instead 853 simply trust that a TA Signer certificate's status was done by the 854 TAM. 856 CA Compromise 857 The CA issuing certificates to a TAM or a TA Signer might get 858 compromised. A compromised intermediate CA certificate can be 859 detected by a TEEP Agent by using OCSP information, assuming the 860 revocation information is available. Additionally, it is 861 RECOMMENDED to provide a way to update the trust anchor store used 862 by the TEE, for example using a firmware update mechanism. If the 863 CA issuing certificates to devices gets compromised then these 864 devices might be rejected by a TAM, if revocation is available to 865 the TAM. 867 Compromised TAM 868 The TEEP Agent SHOULD use OCSP information to verify the validity 869 of the TAM's certificate (as well as the validity of intermediate 870 CA certificates). The integrity and the accuracy of the clock 871 within the TEE determines the ability to determine an expired or 872 revoked certificate. OCSP stapling data includes signature 873 generation time, allowing certificate validity dates to be 874 compared to the current time. 876 Compromised Time Source 877 As discussed above, certificate validity checks rely on comparing 878 validity dates to the current time, which relies on having a 879 trusted source of time, such as [RFC8915]. A compromised time 880 source could thus be used to subvert such validity checks. 882 8. IANA Considerations 884 8.1. Media Type Registration 886 IANA is requested to assign a media type for application/teep+cbor. 888 Type name: application 890 Subtype name: teep+cbor 892 Required parameters: none 894 Optional parameters: none 896 Encoding considerations: Same as encoding considerations of 897 application/cbor. 899 Security considerations: See Security Considerations Section of this 900 document. 902 Interoperability considerations: Same as interoperability 903 considerations of application/cbor as specified in [RFC7049]. 905 Published specification: This document. 907 Applications that use this media type: TEEP protocol implementations 909 Fragment identifier considerations: N/A 911 Additional information: 913 Deprecated alias names for this type: N/A 915 Magic number(s): N/A 917 File extension(s): N/A 919 Macintosh file type code(s): N/A 921 Person to contact for further information: teep@ietf.org 923 Intended usage: COMMON 924 Restrictions on usage: none 926 Author: See the "Authors' Addresses" section of this document 928 Change controller: IETF 930 8.2. Error Code Registry 932 IANA is also requested to create a new registry for the error codes 933 defined in Section 4. 935 Registration requests are evaluated after a three-week review period 936 on the teep-reg-review@ietf.org mailing list, on the advice of one or 937 more Designated Experts [RFC8126]. However, to allow for the 938 allocation of values prior to publication, the Designated Experts may 939 approve registration once they are satisfied that such a 940 specification will be published. 942 Registration requests sent to the mailing list for review should use 943 an appropriate subject (e.g., "Request to register an error code: 944 example"). Registration requests that are undetermined for a period 945 longer than 21 days can be brought to the IESG's attention (using the 946 iesg@ietf.org mailing list) for resolution. 948 Criteria that should be applied by the Designated Experts includes 949 determining whether the proposed registration duplicates existing 950 functionality, whether it is likely to be of general applicability or 951 whether it is useful only for a single extension, and whether the 952 registration description is clear. 954 IANA must only accept registry updates from the Designated Experts 955 and should direct all requests for registration to the review mailing 956 list. 958 8.3. Ciphersuite Registry 960 IANA is also requested to create a new registry for ciphersuites, as 961 defined in Section 6. 963 8.4. CBOR Tag Registry 965 IANA is requested to register a CBOR tag in the "CBOR Tags" registry 966 for use with TEEP messages. 968 The registry contents is: 970 o CBOR Tag: TBD1 971 o Data Item: TEEP Message 973 o Semantics: TEEP Message, as defined in [[TBD: This RFC]] 975 o Reference: [[TBD: This RFC]] 977 o Point of Contact: TEEP working group (teep@ietf.org) 979 9. References 981 9.1. Normative References 983 [I-D.ietf-rats-eat] 984 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 985 O'Donoghue, "The Entity Attestation Token (EAT)", draft- 986 ietf-rats-eat-04 (work in progress), August 2020. 988 [I-D.ietf-suit-manifest] 989 Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, 990 "A Concise Binary Object Representation (CBOR)-based 991 Serialization Format for the Software Updates for Internet 992 of Things (SUIT) Manifest", draft-ietf-suit-manifest-09 993 (work in progress), July 2020. 995 [I-D.moran-suit-report] 996 Moran, B., "Secure Reporting of Update Status", draft- 997 moran-suit-report-00 (work in progress), October 2020. 999 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1000 Requirement Levels", BCP 14, RFC 2119, 1001 DOI 10.17487/RFC2119, March 1997, . 1004 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1005 Adams, "X.509 Internet Public Key Infrastructure Online 1006 Certificate Status Protocol - OCSP", RFC 2560, 1007 DOI 10.17487/RFC2560, June 1999, . 1010 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1011 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1012 2003, . 1014 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 1015 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 1016 . 1018 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1019 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1020 October 2013, . 1022 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1023 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1024 . 1026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1027 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1028 May 2017, . 1030 9.2. Informative References 1032 [I-D.ietf-sacm-coswid] 1033 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. 1034 Waltermire, "Concise Software Identification Tags", draft- 1035 ietf-sacm-coswid-15 (work in progress), May 2020. 1037 [I-D.ietf-teep-architecture] 1038 Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, 1039 "Trusted Execution Environment Provisioning (TEEP) 1040 Architecture", draft-ietf-teep-architecture-12 (work in 1041 progress), July 2020. 1043 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1044 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1045 DOI 10.17487/RFC4122, July 2005, . 1048 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1049 Writing an IANA Considerations Section in RFCs", BCP 26, 1050 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1051 . 1053 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1054 Definition Language (CDDL): A Notational Convention to 1055 Express Concise Binary Object Representation (CBOR) and 1056 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1057 June 2019, . 1059 [RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. 1060 Sundblad, "Network Time Security for the Network Time 1061 Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, 1062 . 1064 A. Contributors 1066 We would like to thank Brian Witten (Symantec), Tyler Kim (Solacia), 1067 Nick Cook (Arm), and Minho Yoo (IoTrust) for their contributions to 1068 the Open Trust Protocol (OTrP), which influenced the design of this 1069 specification. 1071 B. Acknowledgements 1073 We would like to thank Eve Schooler for the suggestion of the 1074 protocol name. 1076 We would like to thank Kohei Isobe (TRASIO/SECOM), Kuniyasu Suzaki 1077 (TRASIO/AIST), Tsukasa Oi (TRASIO), and Yuichi Takita (SECOM) for 1078 their valuable implementation feedback. 1080 We would also like to thank Carsten Bormann and Henk Birkholz for 1081 their help with the CDDL. 1083 C. Complete CDDL 1085 Valid TEEP messages MUST adhere to the following CDDL data 1086 definitions, except that "SUIT_Envelope" is specified in 1087 [I-D.ietf-suit-manifest]. 1089 teep-message = $teep-message-type .within teep-message-framework 1091 SUIT_Envelope = any 1093 teep-message-framework = [ 1094 type: 0..23 / $teep-type-extension, 1095 token: uint, 1096 options: { * teep-option }, 1097 * int; further integers, e.g. for data-item-requested 1098 ] 1100 teep-option = (uint => any) 1102 ; messages defined below: 1103 $teep-message-type /= query-request 1104 $teep-message-type /= query-response 1105 $teep-message-type /= install 1106 $teep-message-type /= delete 1107 $teep-message-type /= teep-success 1108 $teep-message-type /= teep-error 1110 ; message type numbers 1111 TEEP-TYPE-query-request = 1 1112 TEEP-TYPE-query-response = 2 1113 TEEP-TYPE-install = 3 1114 TEEP-TYPE-delete = 4 1115 TEEP-TYPE-teep-success = 5 1116 TEEP-TYPE-teep-error = 6 1118 version = uint .size 4 1119 ext-info = uint 1121 ; data items as bitmaps 1122 data-item-requested = $data-item-requested .within uint .size 8 1123 attestation = 1 1124 $data-item-requested /= attestation 1125 trusted-components = 2 1126 $data-item-requested /= trusted-components 1127 extensions = 4 1128 $data-item-requested /= extensions 1129 suit-commands = 8 1130 $data-item-requested /= suit-commands 1132 query-request = [ 1133 type: TEEP-TYPE-query-request, 1134 token: uint, 1135 options: { 1136 ? supported-cipher-suites => [ + suite ], 1137 ? challenge => bstr .size (8..64), 1138 ? versions => [ + version ], 1139 ? ocsp-data => bstr, 1140 * $$query-request-extensions 1141 * $$teep-option-extensions 1142 }, 1143 data-item-requested 1144 ] 1146 ; ciphersuites as bitmaps 1147 suite = $TEEP-suite .within uint .size 8 1149 TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA = 1 1150 TEEP-AES-CCM-16-64-128-HMAC256--256-P-256-ES256 = 2 1152 $TEEP-suite /= TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA 1153 $TEEP-suite /= TEEP-AES-CCM-16-64-128-HMAC256--256-P-256-ES256 1155 query-response = [ 1156 type: TEEP-TYPE-query-response, 1157 token: uint, 1158 options: { 1159 ? selected-cipher-suite => suite, 1160 ? selected-version => version, 1161 ? evidence-format => text, 1162 ? evidence => bstr, 1163 ? tc-list => [ + tc-info ], 1164 ? requested-tc-list => [ + requested-tc-info ], 1165 ? unneeded-tc-list => [ + bstr ], 1166 ? ext-list => [ + ext-info ], 1167 * $$query-response-extensions, 1168 * $$teep-option-extensions 1169 } 1170 ] 1172 tc-info = { 1173 component-id: bstr, 1174 ? tc-manifest-sequence-number: uint 1175 } 1177 requested-ta-info = { 1178 component-id: bstr, 1179 ? tc-manifest-sequence-number: uint, 1180 ? have-binary: bool 1181 } 1183 install = [ 1184 type: TEEP-TYPE-install, 1185 token: uint, 1186 option: { 1187 ? manifest-list => [ + SUIT_Envelope ], 1188 * $$install-extensions, 1189 * $$teep-option-extensions 1190 } 1191 ] 1193 delete = [ 1194 type: TEEP-TYPE-delete, 1195 token: uint, 1196 option: { 1197 ? tc-list => [ + bstr ], 1198 * $$delete-extensions, 1199 * $$teep-option-extensions 1200 } 1201 ] 1203 teep-success = [ 1204 type: TEEP-TYPE-teep-success, 1205 token: uint, 1206 option: { 1207 ? msg => text, 1208 ? suit-reports => [ + suit-report ], 1209 * $$teep-success-extensions, 1210 * $$teep-option-extensions 1211 } 1212 ] 1214 teep-error = [ 1215 type: TEEP-TYPE-teep-error, 1216 token: uint, 1217 err-code: uint, 1218 options: { 1219 ? err-msg => text, 1220 ? supported-cipher-suites => [ + suite ], 1221 ? versions => [ + version ], 1222 ? suit-reports => [ + suit-report ], 1223 * $$teep-error--extensions, 1224 * $$teep-option-extensions 1225 } 1226 ] 1228 supported-cipher-suites = 1 1229 challenge = 2 1230 versions = 3 1231 ocsp-data = 4 1232 selected-cipher-suite = 5 1233 selected-version = 6 1234 evidence = 7 1235 tc-list = 8 1236 ext-list = 9 1237 manifest-list = 10 1238 msg = 11 1239 err-msg = 12 1240 evidence-format = 13 1241 requested-tc-list = 14 1242 unneeded-tc-list = 15 1243 component-id = 16 1244 tc-manifest-sequence-number = 17 1245 have-binary = 18 1246 suit-reports = 19 1248 D. Examples of Diagnostic Notation and Binary Representation 1250 D.1. Some assumptions in examples 1252 o OCSP stapling data = h'010203' 1254 o TEEP Device will have 2 TAs 1255 * TA-ID: 0x0102030405060708090a0b0c0d0e0f, 1256 0x1102030405060708090a0b0c0d0e0f 1258 o SUIT manifest-list is set empty only for example purposes 1260 o Not including Entity Attestation Token (EAT) parameters for 1261 example purposes 1263 D.2. QueryRequest Message 1265 D.2.1. CBOR Diagnostic Notation 1267 / query-request = / 1268 [ 1269 1, / type : TEEP-TYPE-query-request = 1 (fixed int) / 1270 2004318071, / token : 0x77777777 (uint), generated by TAM / 1271 / options : / 1272 { 1273 1 : [ 1 ] / supported-cipher-suites = 1 (mapkey) : / 1274 / TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA = 1275 [ 1 ] (array of uint .size 8) / 1276 3 : [ 0 ] / version = 3 (mapkey) : 1277 [ 0 ] (array of uint .size 4) / 1278 4 : h'010203' / ocsp-data = 4 (mapkey) : 0x010203 (bstr) / 1279 }, 1280 2 / data-item-requested : trusted-components = 2 (uint) / 1281 ] 1283 D.2.2. CBOR Binary Representation 1285 84 # array(4), 1286 01 # unsigned(1) 1287 1A 77777777 # unsigned(2004318071, 0x77777777) 1288 A3 # map(3) 1289 01 # unsigned(1) 1290 81 # array(1) 1291 01 # unsigned(1) within .size 8 1292 03 # unsigned(3) 1293 81 # array(1) 1294 00 # unsigned(0) within .size 4 1295 04 # unsigned(4) 1296 43 # bytes(3) 1297 010203 # "\x01\x02\x03" 1298 02 # unsigned(2) 1300 D.3. QueryResponse Message 1302 D.3.1. CBOR Diagnostic Notation 1304 / query-response = / 1305 [ 1306 2, / type : TEEP-TYPE-query-response = 2 (fixed int) / 1307 2004318071, / token : 0x77777777 (uint), from TAM's QueryRequest 1308 message / 1309 / options : / 1310 { 1311 5 : 1, / selected-cipher-suite = 5(mapkey) :/ 1312 / TEEP-AES-CCM-16-64-128-HMAC256--256-X25519-EdDSA = 1313 1 (uint .size 8) / 1314 6 : 0, / selected-version = 6 (mapkey) : 0 (uint .size 4) / 1315 8 : [ h'0102030405060708090a0b0c0d0e0f', 1316 h'1102030405060708090a0b0c0d0e0f' ] 1317 / ta-list = 8 (mapkey) : 1318 [ 0x0102030405060708090a0b0c0d0e0f, 1319 0x1102030405060708090a0b0c0d0e0f ] 1320 (array of bstr) / 1321 } 1322 ] 1324 D.3.2. CBOR Binary Representation 1326 83 # array(3) 1327 02 # unsigned(2) 1328 1A 77777777 # unsigned(2004318071, 0x77777777) 1329 A3 # map(3) 1330 05 # unsigned(5) 1331 01 # unsigned(1) within .size 8 1332 06 # unsigned(6) 1333 00 # unsigned(0) within .size 4 1334 08 # unsigned(8) 1335 82 # array(2) 1336 4F # bytes(16) 1337 0102030405060708090A0B0C0D0D0F 1338 4F # bytes(16) 1339 1102030405060708090A0B0C0D0D0F 1341 D.4. Install Message 1343 D.4.1. CBOR Diagnostic Notation 1344 / install = / 1345 [ 1346 3, / type : TEEP-TYPE-install = 3 (fixed int) / 1347 2004318072, / token : 0x777777778 (uint), generated by TAM / 1348 / options : / 1349 { 1350 10 : [ ] / manifest-list = 10 (mapkey) : 1351 [ ] (array of SUIT_Envelope(any)) / 1352 / empty, example purpose only / 1353 } 1354 ] 1356 D.4.2. CBOR Binary Representation 1358 83 # array(3) 1359 03 # unsigned(3) 1360 1A 77777778 # unsigned(2004318072, 0x77777778) 1361 A1 # map(1) 1362 0A # unsigned(10) 1363 80 # array(0) 1365 D.5. Success Message (for Install) 1367 D.5.1. CBOR Diagnostic Notation 1369 / teep-success = / 1370 [ 1371 5, / type : TEEP-TYPE-teep-success = 5 (fixed int) / 1372 2004318072, / token : 0x777777778 (uint), from Install message / 1373 ] 1375 D.5.2. CBOR Binary Representation 1377 83 # array(3) 1378 05 # unsigned(5) 1379 1A 77777778 # unsigned(2004318072, 0x77777778) 1381 D.6. Error Message (for Install) 1383 D.6.1. CBOR Diagnostic Notation 1384 / teep-error = / 1385 [ 1386 6, / type : TEEP-TYPE-teep-error = 6 (fixed int) / 1387 2004318072, / token : 0x777777778 (uint), from Install message / 1388 ERR_MANIFEST_PROCESSING_FAILED, 1389 / err-code : ERR_MANIFEST_PROCESSING_FAILED = 17 (uint) / 1390 / options : / 1391 { 1392 12 : "disk-full" / err-msg = 12 (mapkey) : 1393 "disk-full" (UTF-8 string) / 1394 } 1395 ] 1397 D.6.2. CBOR binary Representation 1399 83 # array(3) 1400 06 # unsigned(6) 1401 1A 77777778 # unsigned(2004318072, 0x77777778) 1402 11 # unsigned(17) 1403 A1 # map(1) 1404 0B # unsigned(12) 1405 69 # text(9) 1406 6469736b2d66756c6c # "disk-full" 1408 Authors' Addresses 1410 Hannes Tschofenig 1411 Arm Ltd. 1412 Absam, Tirol 6067 1413 Austria 1415 Email: hannes.tschofenig@arm.com 1417 Mingliang Pei 1418 Broadcom 1419 350 Ellis St 1420 Mountain View, CA 94043 1421 USA 1423 Email: mingliang.pei@broadcom.com 1425 David Wheeler 1426 Intel 1427 US 1429 Email: david.m.wheeler@intel.com 1430 Dave Thaler 1431 Microsoft 1432 US 1434 Email: dthaler@microsoft.com 1436 Akira Tsukamoto 1437 AIST 1438 JP 1440 Email: akira.tsukamoto@aist.go.jp