idnits 2.17.00 (12 Aug 2021) /tmp/idnits11711/draft-ietf-teep-protocol-01.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 (March 9, 2020) is 802 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) == Unused Reference: 'RFC4648' is defined on line 707, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-rats-eat-03 == Outdated reference: A later version (-17) exists of draft-ietf-suit-manifest-03 ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: draft-ietf-cbor-cddl has been published as RFC 8610 == Outdated reference: A later version (-17) exists of draft-ietf-teep-architecture-07 Summary: 2 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: September 10, 2020 Broadcom 6 D. Wheeler 7 Intel 8 D. Thaler 9 Microsoft 10 March 9, 2020 12 Trusted Execution Environment Provisioning (TEEP) Protocol 13 draft-ietf-teep-protocol-01 15 Abstract 17 This document specifies a protocol that installs, updates, and 18 deletes Trusted Applications (TAs) in a device with a Trusted 19 Execution Environment (TEE). This specification defines an 20 interoperable protocol for managing the lifecycle of TAs. 22 The protocol name is pronounced teepee. This conjures an image of a 23 wedge-shaped protective covering for one's belongings, which sort of 24 matches the intent of this protocol. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 10, 2020. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 62 3. Message Overview . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Detailed Messages Specification . . . . . . . . . . . . . . . 5 64 4.1. QueryRequest . . . . . . . . . . . . . . . . . . . . . . 5 65 4.2. QueryResponse . . . . . . . . . . . . . . . . . . . . . . 7 66 4.3. TrustedAppInstall . . . . . . . . . . . . . . . . . . . . 7 67 4.4. TrustedAppDelete . . . . . . . . . . . . . . . . . . . . 8 68 4.5. Success . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 4.6. Error . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 11 71 6. Security Consideration . . . . . . . . . . . . . . . . . . . 12 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 7.1. Media Type Registration . . . . . . . . . . . . . . . . . 13 74 7.2. Error Code Registry . . . . . . . . . . . . . . . . . . . 14 75 7.3. Ciphersuite Registry . . . . . . . . . . . . . . . . . . 15 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 78 8.2. Informative References . . . . . . . . . . . . . . . . . 16 79 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16 80 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 17 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 83 1. Introduction 85 The Trusted Execution Environment (TEE) concept has been designed to 86 separate a regular operating system, also referred as a Rich 87 Execution Environment (REE), from security-sensitive applications. 88 In an TEE ecosystem, device vendors may use different operating 89 systems in the REE and may use different types of TEEs. When 90 application providers or device administrators use Trusted 91 Application Managers (TAMs) to install, update, and delete Trusted 92 Applications (TAs) on a wide range of devices with potentially 93 different TEEs then an interoperability need arises. 95 This document specifies the protocol for communicating between a TAM 96 and a TEEP Agent, involving a TEEP Broker. 98 The Trusted Execution Environment Provisioning (TEEP) architecture 99 document [I-D.ietf-teep-architecture] has set to provide a design 100 guidance for such an interoperable protocol and introduces the 101 necessary terminology. Note that the term Trusted Application may 102 include more than code; it may also include configuration data and 103 keys needed by the TA to operate correctly. 105 2. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 This specification re-uses the terminology defined in 112 [I-D.ietf-teep-architecture]. 114 3. Message Overview 116 The TEEP protocol consists of a couple of messages exchanged between 117 a TAM and a TEEP Agent via a TEEP Broker. The messages are encoded 118 in CBOR and designed to provide end-to-end security. TEEP protocol 119 messages are signed by the endpoints, i.e., the TAM and the TEEP 120 Agent, but trusted applications may as well be encrypted and signed 121 by the service provider. The TEEP protocol not only re-use CBOR but 122 also the respective security wrapper, namely COSE [RFC8152]. 123 Furthermore, for attestation the Entity Attestation Token (EAT) 124 [I-D.ietf-rats-eat] and for software updates the SUIT manifest format 125 [I-D.ietf-suit-manifest] are re-used. 127 This specification defines six messages. 129 A TAM queries a device's current state with a QueryRequest message. 130 A TEEP Agent will, after authenticating and authorizing the request, 131 report attestation information, list all TAs, and provide information 132 about supported algorithms and extensions in a QueryResponse message. 133 An error message is returned if the request could not be processed. 134 A TAM will process the QueryResponse message and determine whether 135 subsequent message exchanges to install, update, or delete trusted 136 applications shall be initiated. 138 +------------+ +-------------+ 139 | TAM | |TEEP Agent | 140 +------------+ +-------------+ 142 QueryRequest -------> 144 QueryResponse 146 <------- or 148 Error 150 With the TrustedAppInstall message a TAM can instruct a TEEP Agent to 151 install a TA. The TEEP Agent will process the message, determine 152 whether the TAM is authorized and whether the TA has been signed by 153 an authorized SP. In addition to the binary, the TAM may also 154 provide personalization data. If the TrustedAppInstall message was 155 processed successfully then a Success message is returned to the TAM, 156 an Error message otherwise. 158 +------------+ +-------------+ 159 | TAM | |TEEP Agent | 160 +------------+ +-------------+ 162 TrustedAppInstall ----> 164 Success 166 <---- or 168 Error 170 With the TrustedAppDelete message a TAM can instruct a TEEP Agent to 171 delete one or multiple TA(s). A Success message is returned when the 172 operation has been completed successfully, and an Error message 173 otherwise. 175 +------------+ +-------------+ 176 | TAM | |TEEP Agent | 177 +------------+ +-------------+ 179 TrustedAppDelete ----> 181 Success 183 <---- or 185 Error 187 4. Detailed Messages Specification 189 The CBOR-encoded messages are protected by COSE, as described in CDDL 190 format [I-D.ietf-cbor-cddl] below. 192 Outer_Wrapper = { 193 msg-authenc-wrapper => bstr .cbor 194 Msg_AuthEnc_Wrapper / nil, 195 teep-message => (QueryRequest / 196 QueryResponse / 197 TrustedAppInstall / 198 TrustedAppDelete / 199 Error / 200 Success ), 201 } 203 msg-authenc-wrapper = 1 204 teep-message = 2 206 Msg_AuthEnc_Wrapper = [ * (COSE_Mac_Tagged / 207 COSE_Sign_Tagged / 208 COSE_Mac0_Tagged / 209 COSE_Sign1_Tagged)] 211 4.1. QueryRequest 213 suite = int 215 version = int 217 data_item = int 219 QueryRequest = { 220 TYPE : int, 221 TOKEN : bstr, 222 REQUEST : [+data_item], 223 ? CIPHER_SUITE : [+suite], 224 ? NONCE : bstr, 225 ? VERSION : [+version], 226 ? OCSP_DATA : bstr, 227 * $$extensions 228 } 230 A QueryRequest message is signed by the TAM and has the following 231 fields: 233 TYPE TYPE = 1 corresponds to a QueryRequest message sent from the 234 TAM to the TEEP Agent. 236 TOKEN The value in the TOKEN field is used to match requests to 237 responses. 239 REQUEST The REQUEST field indicates what information the TAM 240 requests from the TEEP Agent in form of a list of integer values. 241 Each integer value corresponds to an IANA registered information 242 element. This specification defines the initial set of 243 information elements: 245 attestation (1) With this value the TAM requests the TEEP Agent 246 to return an entity attestation token (EAT) in the response. 248 trusted_apps (2) With this value the TAM queries the TEEP Agent 249 for all installed TAs. 251 extensions (3) With this value the TAM queries the TEEP Agent for 252 supported capabilities and extensions, which allows a TAM to 253 discover the capabilities of a TEEP Agent implementation. 255 suit_commands (4) With this value the TAM queries the TEEP Agent 256 for supported commands offered by the SUIT manifest 257 implementation. 259 Further values may be added in the future via IANA registration. 261 CIPHER_SUITE The CIPHER_SUITE field lists the ciphersuite(s) 262 supported by the TAM. Details about the ciphersuite encoding can 263 be found in Section 5. 265 NONCE NONCE is an optional field used for ensuring the refreshness 266 of the Entity Attestation Token (EAT) contained in the response. 268 VERSION The VERSION field lists the version(s) supported by the TAM. 269 For this version of the specification this field can be omitted. 271 OCSP_DATA The OCSP_DATA field contains a list of OCSP stapling data 272 respectively for the TAM certificate and each of the CA 273 certificates up to the root certificate. The TAM provides OCSP 274 data so that the TEEP Agent can validate the status of the TAM 275 certificate chain without making its own external OCSP service 276 call. OCSP data MUST be conveyed as a DER-encoded OCSP response 277 (using the ASN.1 type OCSPResponse defined in [RFC2560]). The use 278 of OCSP is optional to implement for bo th the TAM and the TEEP 279 Agent. A TAM can query the TEEP Agent for the support of this 280 functionality via the capability discovery exchange, as described 281 above. 283 4.2. QueryResponse 285 ext_info = int 287 QueryResponse = { 288 TYPE : int, 289 TOKEN : bstr, 290 ? SELECTED_CIPHER_SUITE : suite, 291 ? SELECTED_VERSION : version, 292 ? EAT : bstr, 293 ? TA_LIST : [+bstr], 294 ? EXT_LIST : [+ext_info], 295 * $$extensions 296 } 298 The QueryResponse message is signed and encrypted by the TEEP Agent 299 and returned to the TAM. It has the following fields: 301 TYPE TYPE = 2 corresponds to a QueryResponse message sent from the 302 TEEP Agent to the TAM. 304 TOKEN The value in the TOKEN field is used to match requests to 305 responses. The value MUST correspond to the value received with 306 the QueryRequest. 308 SELECTED_CIPHER_SUITE The SELECTED_CIPHER_SUITE field indicates the 309 selected ciphersuite. Details about the ciphersuite encoding can 310 be found in Section 5. 312 SELECTED_VERSION The SELECTED_VERSION field indicates the protocol 313 version selected by the TEEP Agent. 315 EAT The EAT field contains an Entity Attestation Token following the 316 encoding defined in [I-D.ietf-rats-eat]. 318 TA_LIST The TA_LIST field enumerates the trusted applications 319 installed on the device in form of TA ID strings. 321 EXT_LIST The EXT_LIST field lists the supported extensions. This 322 document does not define any extensions. 324 4.3. TrustedAppInstall 325 TrustedAppInstall = { 326 TYPE : int, 327 TOKEN : bstr, 328 ? MANIFEST_LIST : [+ SUIT_Outer_Wrapper], 329 * $$extensions 330 } 332 The TrustedAppInstall message is MACed and encrypted by the TAM and 333 has the following fields: 335 TYPE TYPE = 3 corresponds to a TrustedAppInstall message sent from 336 the TAM to the TEEP Agent. In case of successful processing, an 337 Success message is returned by the TEEP Agent. In case of an 338 error, an Error message is returned. Note that the 339 TrustedAppInstall message is used for initial TA installation but 340 also for TA updates. 342 TOKEN The value in the TOKEN field is used to match requests to 343 responses. 345 TA The MANIFEST_LIST field is used to convey one or multiple SUIT 346 manifests. A manifest is a bundle of metadata about the trusted 347 app, where to find the code, the devices to which it applies, and 348 cryptographic information protecting the manifest. The manifest 349 may also convey personalization data. TA binaries and 350 personalization data is typically signed and encrypted by the SP. 351 Other combinations are, however, possible as well. For example, 352 it is also possible for the TAM to sign and encrypt the 353 personalization data and to let the SP sign and/or encrypt the TA 354 binary. 356 4.4. TrustedAppDelete 358 TrustedAppDelete = { 359 TYPE : int, 360 TOKEN : bstr, 361 ? TA_LIST : [+bstr], 362 * $$extensions 363 } 365 The TrustedAppDelete message is MACed and encrypted by the TAM and 366 has the following fields: 368 TYPE TYPE = 4 corresponds to a TrustedAppDelete message sent from 369 the TAM to the TEEP Agent. In case of successful processing, an 370 Success message is returned by the TEEP Agent. In case of an 371 error, an Error message is returned. 373 TOKEN The value in the TOKEN field is used to match requests to 374 responses. 376 TA_LIST The TA_LIST field enumerates the TAs to be deleted. 378 4.5. Success 380 Success = { 381 TYPE : int, 382 TOKEN : bstr, 383 ? MSG : tstr, 384 * $$extensions 385 } 387 The Success message is MACed and encrypted by the TEEP Agent and has 388 the following fields: 390 TYPE TYPE = 5 corresponds to a Error message sent from the TEEP 391 Agent to the TAM. 393 TOKEN The value in the TOKEN field is used to match requests to 394 responses. 396 MSG The MSG field contains optional diagnostics information encoded 397 in UTF-8 [RFC3629] returned by the TEEP Agent. 399 4.6. Error 401 Error = { 402 TYPE : int, 403 TOKEN : bstr, 404 ERR_CODE : int, 405 ? ERR_MSG : tstr, 406 ? CIPHER_SUITE : [+suite], 407 ? VERSION : [+version], 408 * $$extensions 409 } 411 If possible, the Error message is MACed and encrypted by the TEEP 412 Agent. Unprotected Error messages MUST be handled with care by the 413 TAM due to possible downgrading attacks. It has the following 414 fields: 416 TYPE TYPE = 6 corresponds to a Error message sent from the TEEP 417 Agent to the TAM. 419 TOKEN The value in the TOKEN field is used to match requests to 420 responses. 422 ERR_CODE The ERR_CODE field is populated with values listed in a 423 registry (with the initial set of error codes listed below). Only 424 selected messages are applicable to each message. 426 ERR_MSG The ERR_MSG message is a human-readable diagnostic message 427 that MUST be encoded using UTF-8 [RFC3629] using Net-Unicode form 428 [RFC5198]. 430 VERSION The VERSION field enumerates the protocol version(s) 431 supported by the TEEP Agent. This field is optional but MUST be 432 returned with the ERR_UNSUPPORTED_MSG_VERSION error message. 434 CIPHER_SUITE The CIPHER_SUITE field lists the ciphersuite(s) 435 supported by the TEEP Agent. This field is optional but MUST be 436 returned with the ERR_UNSUPPORTED_CRYPTO_ALG error message. 438 This specification defines the following initial error messages. 439 Additional error code can be registered with IANA. 441 ERR_ILLEGAL_PARAMETER (1) The TEEP Agent sends this error message 442 when a request contains incorrect fields or fields that are 443 inconsistent with other fields. 445 ERR_UNSUPPORTED_EXTENSION (2) The TEEP Agent sends this error 446 message when it recognizes an unsupported extension or unsupported 447 message. 449 ERR_REQUEST_SIGNATURE_FAILED (3) The TEEP Agent sends this error 450 message when it fails to verify the signature of the message. 452 ERR_UNSUPPORTED_MSG_VERSION (4) The TEEP Agent receives a message 453 but does not support the indicated version. 455 ERR_UNSUPPORTED_CRYPTO_ALG (5) The TEEP Agent receives a request 456 message encoded with an unsupported cryptographic algorithm. 458 ERR_BAD_CERTIFICATE (6) The TEEP Agent returns this error when 459 processing of a certificate failed. For diagnosis purposes it is 460 RECOMMMENDED to include information about the failing certificate 461 in the error message. 463 ERR_UNSUPPORTED_CERTIFICATE (7) The TEEP Agent returns this error 464 when a certificate was of an unsupported type. 466 ERR_CERTIFICATE_REVOKED (8) The TEEP Agent returns this error when a 467 certificate was revoked by its signer. 469 ERR_CERTIFICATE_EXPIRED (9) The TEEP Agent returns this error when a 470 certificate has expired or is not currently valid. 472 ERR_INTERNAL_ERROR (10) The TEEP Agent returns this error when a 473 miscellaneous internal error occurred while processing the 474 request. 476 ERR_RESOURCE_FULL (11) This error is reported when a device resource 477 isn't available anymore, such as storage space is full. 479 ERR_TA_NOT_FOUND (12) This error will occur when the target TA does 480 not exist. This error may happen when the TAM has stale 481 information and tries to delete a TA that has already been 482 deleted. 484 ERR_TA_ALREADY_INSTALLED (13) While installing a TA, a TEE will 485 return this error if the TA has already been installed. 487 ERR_TA_UNKNOWN_FORMAT (14) The TEEP Agent returns this error when it 488 does not recognize the format of the TA binary. 490 ERR_TA_DECRYPTION_FAILED (15) The TEEP Agent returns this error when 491 it fails to decrypt the TA binary. 493 ERR_TA_DECOMPRESSION_FAILED (16) The TEEP Agent returns this error 494 when it fails to decompress the TA binary. 496 ERR_MANIFEST_PROCESSING_FAILED (17) The TEEP Agent returns this 497 error when manifest processing failures occur that are less 498 specific than ERR_TA_UNKNOWN_FORMAT, ERR_TA_UNKNOWN_FORMAT, and 499 ERR_TA_DECOMPRESSION_FAILED. 501 ERR_PD_PROCESSING_FAILED (18) The TEEP Agent returns this error when 502 it fails to process the provided personalization data. 504 5. Ciphersuites 506 A ciphersuite consists of an AEAD algorithm, a HMAC algorithm, and a 507 signature algorithm. Each ciphersuite is identified with an integer 508 value, which corresponds to an IANA registered ciphersuite. This 509 document specifies two ciphersuites. 511 Value | Ciphersuite 512 ------+------------------------------------------------ 513 0 | AES-CCM-16-64-128, HMAC 256/256, X25519, EdDSA 514 1 | AES-CCM-16-64-128, HMAC 256/256, P-256, ES256 516 6. Security Consideration 518 This section summarizes the security considerations discussed in this 519 specification: 521 Cryptographic Algorithms TEEP protocol messages exchanged between 522 the TAM and the TEEP Agent are protected using COSE. This 523 specification relies on the cryptographic algorithms provided by 524 COSE. Public key based authentication is used to by the TEEP 525 Agent to authenticate the TAM and vice versa. 527 Attestation A TAM may rely on the attestation information provided 528 by the TEEP Agent and the Entity Attestation Token is re-used to 529 convey this information. To sign the Entity Attestation Token it 530 is necessary for the device to possess a public key (usually in 531 the form of a certificate) along with the corresponding private 532 key. Depending on the properties of the attestation mechanism it 533 is possible to uniquely identify a device based on information in 534 the attestation information or in the certificate used to sign the 535 attestation token. This uniqueness may raise privacy concerns. 536 To lower the privacy implications the TEEP Agent MUST present its 537 attestation information only to an authenticated and authorized 538 TAM. 540 TA Binaries TA binaries are provided by the SP.It is the 541 responsibility of the TAM to relay only verified TAs from 542 authorized SPs. Delivery of that TA to the TEEP Agent is then the 543 responsibility of the TAM and the TEEP Broker, using the security 544 mechanisms provided by the TEEP protocol. To protect the TA 545 binary the SUIT manifest is re-used and it offers a varity of 546 security features, including digitial signatures and symmetric 547 encryption. 549 Personalization Data An SP or a TAM can supply personalization data 550 along with a TA. This data is also protected by a SUIT manifest. 551 The personalization data may be opaque to the TAM. 553 TEEP Broker The TEEP protocol relies on the TEEP Broker to relay 554 messages between the TAM and the TEEP Agent. When the TEEP Broker 555 is compromised it can drop messages, delay the delivery of 556 messages, and replay messages but it cannot modify those messages. 557 (A replay would be, however, detected by the TEEP Agent.) A 558 compromised TEEP Broker could reorder messages in an attempt to 559 install an old version of a TA. Information in the manifest 560 ensures that the TEEP Agents are protected against such 561 downgrading attacks based on features offered by the manifest 562 itself. 564 CA Compromise The QueryRequest message from a TAM to the TEEP Agent 565 may include OCSP stapling data for the TAM's signer certificate 566 and for intermediate CA certificates up to the root certificate so 567 that the TEEP Agent can verify the certificate's revocation 568 status. 570 A certificate revocation status check on a TA signer certificate 571 is OPTIONAL by a TEEP Agent. A TAM is responsible for vetting a 572 TA and before distributing them to TEEP Agents. TEEP Agents will 573 trust a TA signer certificate's validation status done by a TAM. 575 CA Compromise The CA issuing certificates to a TAM or an SP may get 576 compromised. A compromised intermediate CA certificates can be 577 detected by a TEEP Agent by using OCSP information, assuming the 578 revocation information is available. Additionally, it is 579 RECOMMENDED to provide a way to update the trust anchor store used 580 by the device, for example using a firmware update mechanism. 582 If the CA issuing certificates to devices gets compromised then 583 these devices might be rejected by a TAM, if revocation is 584 available to the TAM. 586 Compromised TAM The TEEP Agent SHOULD use OCSP information to verify 587 the validity of the TAM-provided certificate (as well as the 588 validity of intermediate CA certificates). The integrity and the 589 accuracy of the clock within the TEE determines the ability to 590 determine an expired or revoked certificate since OCSP stapling 591 includes signature generation time, certificate validity dates are 592 compared to the current time. 594 7. IANA Considerations 596 7.1. Media Type Registration 598 IANA is requested to assign a media type for application/teep+cbor. 600 Type name: application 602 Subtype name: teep+cbor 604 Required parameters: none 606 Optional parameters: none 608 Encoding considerations: Same as encoding considerations of 609 application/cbor 611 Security considerations: See Security Considerations Section of this 612 document. 614 Interoperability considerations: Same as interoperability 615 considerations of application/cbor as specified in [RFC7049] 617 Published specification: This document. 619 Applications that use this media type: TEEP protocol implementations 621 Fragment identifier considerations: N/A 623 Additional information: 625 Deprecated alias names for this type: N/A 627 Magic number(s): N/A 629 File extension(s): N/A 631 Macintosh file type code(s): N/A 633 Person to contact for further information: teep@ietf.org 635 Intended usage: COMMON 637 Restrictions on usage: none 639 Author: See the "Authors' Addresses" section of this document 641 Change controller: IETF 643 7.2. Error Code Registry 645 IANA is also requested to create a new registry for the error codes 646 defined in Section 4. 648 Registration requests are evaluated after a three-week review period 649 on the teep-reg-review@ietf.org mailing list, on the advice of one or 650 more Designated Experts [RFC8126]. However, to allow for the 651 allocation of values prior to publication, the Designated Experts may 652 approve registration once they are satisfied that such a 653 specification will be published. 655 Registration requests sent to the mailing list for review should use 656 an appropriate subject (e.g., "Request to register an error code: 657 example"). Registration requests that are undetermined for a period 658 longer than 21 days can be brought to the IESG's attention (using the 659 iesg@ietf.org mailing list) for resolution. 661 Criteria that should be applied by the Designated Experts includes 662 determining whether the proposed registration duplicates existing 663 functionality, whether it is likely to be of general applicability or 664 whether it is useful only for a single extension, and whether the 665 registration description is clear. 667 IANA must only accept registry updates from the Designated Experts 668 and should direct all requests for registration to the review mailing 669 list. 671 7.3. Ciphersuite Registry 673 IANA is also requested to create a new registry for ciphersuites, as 674 defined in Section 5. 676 8. References 678 8.1. Normative References 680 [I-D.ietf-rats-eat] 681 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 682 O'Donoghue, "The Entity Attestation Token (EAT)", draft- 683 ietf-rats-eat-03 (work in progress), February 2020. 685 [I-D.ietf-suit-manifest] 686 Moran, B., Tschofenig, H., and H. Birkholz, "A Concise 687 Binary Object Representation (CBOR)-based Serialization 688 Format for the Software Updates for Internet of Things 689 (SUIT) Manifest", draft-ietf-suit-manifest-03 (work in 690 progress), February 2020. 692 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 693 Requirement Levels", BCP 14, RFC 2119, 694 DOI 10.17487/RFC2119, March 1997, 695 . 697 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 698 Adams, "X.509 Internet Public Key Infrastructure Online 699 Certificate Status Protocol - OCSP", RFC 2560, 700 DOI 10.17487/RFC2560, June 1999, 701 . 703 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 704 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 705 2003, . 707 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 708 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 709 . 711 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 712 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 713 . 715 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 716 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 717 October 2013, . 719 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 720 RFC 8152, DOI 10.17487/RFC8152, July 2017, 721 . 723 8.2. Informative References 725 [I-D.ietf-cbor-cddl] 726 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 727 definition language (CDDL): a notational convention to 728 express CBOR and JSON data structures", draft-ietf-cbor- 729 cddl-08 (work in progress), March 2019. 731 [I-D.ietf-teep-architecture] 732 Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, 733 "Trusted Execution Environment Provisioning (TEEP) 734 Architecture", draft-ietf-teep-architecture-07 (work in 735 progress), March 2020. 737 [I-D.ietf-teep-opentrustprotocol] 738 Pei, M., Atyeo, A., Cook, N., Yoo, M., and H. Tschofenig, 739 "The Open Trust Protocol (OTrP)", draft-ietf-teep- 740 opentrustprotocol-03 (work in progress), May 2019. 742 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 743 Writing an IANA Considerations Section in RFCs", BCP 26, 744 RFC 8126, DOI 10.17487/RFC8126, June 2017, 745 . 747 Appendix A. Acknowledgements 749 This work is based on the initial version of OTrP 750 [I-D.ietf-teep-opentrustprotocol] and hence credits go to those who 751 have contributed to it. 753 We would like to thank Eve Schooler for the suggestion of the 754 protocol name. 756 We would like to thank Akira Tsukamoto, Isobe Kohei, Kohei Isobe, 757 Tsukasa Ooi, and Yuichi Takita for their valuable implementation 758 feedback. 760 Appendix B. Contributors 762 We would like to thank the following individuals for their 763 contributions to an initial version of this specification. 765 - Brian Witten 766 Symantec 767 brian_witten@symantec.com 769 - Tyler Kim 770 Solacia 771 tylerkim@iotrust.kr 773 - Nick Cook 774 Arm Ltd. 775 nicholas.cook@arm.com 777 - Minho Yoo 778 IoTrust 779 minho.yoo@iotrust.kr 781 Authors' Addresses 783 Hannes Tschofenig 784 Arm Ltd. 785 Absam, Tirol 6067 786 Austria 788 Email: hannes.tschofenig@arm.com 790 Mingliang Pei 791 Broadcom 792 350 Ellis St 793 Mountain View, CA 94043 794 USA 796 Email: mingliang.pei@broadcom.com 797 David Wheeler 798 Intel 799 US 801 Email: david.m.wheeler@intel.com 803 Dave Thaler 804 Microsoft 805 US 807 Email: dthaler@microsoft.com