idnits 2.17.1 draft-ietf-teep-protocol-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 (December 7, 2019) is 1602 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 772, but no explicit reference was found in the text == Unused Reference: 'RFC7517' is defined on line 796, but no explicit reference was found in the text == Unused Reference: 'RFC7518' is defined on line 800, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-01 == Outdated reference: A later version (-25) exists of draft-ietf-suit-manifest-02 ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-19) exists of draft-ietf-teep-architecture-04 Summary: 4 errors (**), 0 flaws (~~), 7 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: June 9, 2020 Broadcom 6 D. Wheeler 7 Intel 8 D. Thaler 9 Microsoft 10 December 7, 2019 12 Trusted Execution Environment Provisioning (TEEP) Protocol 13 draft-ietf-teep-protocol-00 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 June 9, 2020. 43 Copyright Notice 45 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . 9 67 4.4. TrustedAppDelete . . . . . . . . . . . . . . . . . . . . 9 68 4.5. Success . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 4.6. Error . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 5. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 12 71 6. Security Consideration . . . . . . . . . . . . . . . . . . . 13 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 7.1. Media Type Registration . . . . . . . . . . . . . . . . . 14 74 7.2. Error Code Registry . . . . . . . . . . . . . . . . . . . 16 75 7.3. Ciphersuite Registry . . . . . . . . . . . . . . . . . . 17 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 78 8.2. Informative References . . . . . . . . . . . . . . . . . 18 79 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 80 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 19 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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, different device vendors may use different 89 operating systems in the REE and may use different types of TEEs. 90 When 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 either in JSON or CBOR and designed to provide end-to-end security. 119 TEEP protocol messages are signed and/or encrypted by the endpoints, 120 i.e., the TAM and the TEEP Agent, but trusted applications may as 121 well be encrypted and signed by the service provider. The TEEP 122 protocol not only re-use JSON and CBOR but also the respective 123 security wrappers, namely JOSE (JWS [RFC7515] and JWE [RFC7516], to 124 be more specific) and COSE [RFC8152]. Furthermore, for attestation 125 the Entity Attestation Token (EAT) [I-D.ietf-rats-eat] and for 126 software updates the SUIT manifest format [I-D.ietf-suit-manifest] 127 are re-used. 129 This specification defines six messages. 131 A TAM queries a device's current state with a QueryRequest message. 132 A TEEP Agent will, after authenticating and authorizing the request, 133 report attestation information, list all TAs, and provide information 134 about supported algorithms and extensions in a QueryResponse message. 135 An error message is returned if the request could not be processed. 136 A TAM will process the QueryResponse message and determine whether 137 subsequent message exchanges to install, update, or delete trusted 138 applications shall be initiated. 140 +------------+ +-------------+ 141 | TAM | |TEEP Agent | 142 +------------+ +-------------+ 144 QueryRequest -------> 146 QueryResponse 148 <------- or 150 Error 152 With the TrustedAppInstall message a TAM can instruct a TEEP Agent to 153 install a TA. The TEEP Agent will process the message, determine 154 whether the TAM is authorized and whether the TA has been signed by 155 an authorized SP. In addition to the binary, the TAM may also 156 provide personalization data. If the TrustedAppInstall message was 157 processed successfully then a Success message is returned to the TAM, 158 an Error message otherwise. 160 +------------+ +-------------+ 161 | TAM | |TEEP Agent | 162 +------------+ +-------------+ 164 TrustedAppInstall ----> 166 Success 168 <---- or 170 Error 172 With the TrustedAppDelete message a TAM can instruct a TEEP Agent to 173 delete one or multiple TA(s). A Success message is returned when the 174 operation has been completed successfully, and an Error message 175 otherwise. 177 +------------+ +-------------+ 178 | TAM | |TEEP Agent | 179 +------------+ +-------------+ 181 TrustedAppDelete ----> 183 Success 185 <---- or 187 Error 189 4. Detailed Messages Specification 191 For a CBOR-based encoding the following security wrapper is used 192 (described in CDDL format [I-D.ietf-cbor-cddl]). 194 Outer_Wrapper = { 195 msg-authenc-wrapper => bstr .cbor 196 Msg_AuthEnc_Wrapper / nil, 197 teep-message => (QueryRequest / 198 QueryResponse / 199 TrustedAppInstall / 200 TrustedAppDelete / 201 Error / 202 Success ), 203 } 205 msg-authenc-wrapper = 1 206 teep-message = 2 208 Msg_AuthEnc_Wrapper = [ * (COSE_Mac_Tagged / 209 COSE_Sign_Tagged / 210 COSE_Mac0_Tagged / 211 COSE_Sign1_Tagged)] 213 A future version of this specification will also describe the 214 security wrapper for JSON (in CDDL format). 216 4.1. QueryRequest 217 suite = int 219 version = int 221 data_items = ( 222 attestation: 1, 223 trusted_apps: 2, 224 extensions: 3, 225 suit_commands: 4 226 ) 228 QueryRequest = ( 229 TYPE : int, 230 TOKEN : bstr, 231 REQUEST : [+data_items], 232 ? CIPHER_SUITE : [+suite], 233 ? NONCE : bstr, 234 ? VERSION : [+version], 235 ? OCSP_DATA : bstr, 236 * $$extensions 237 ) 239 A QueryRequest message is signed by the TAM and has the following 240 fields: 242 TYPE TYPE = 1 corresponds to a QueryRequest message sent from the 243 TAM to the TEEP Agent. 245 TOKEN The value in the TOKEN field is used to match requests to 246 responses. 248 REQUEST The REQUEST field indicates what information the TAM 249 requests from the TEEP Agent in form of a list of integer values. 250 Each integer value corresponds to an IANA registered information 251 element. This specification defines the initial set of 252 information elements: 254 attestation (1) With this value the TAM requests the TEEP Agent 255 to return an entity attestation token (EAT) in the response. 257 trusted_apps (2) With this value the TAM queries the TEEP Agent 258 for all installed TAs. 260 extensions (3) With this value the TAM queries the TEEP Agent for 261 supported capabilities and extensions, which allows a TAM to 262 discover the capabilities of a TEEP Agent implementation. 264 suit_commands (4) With this value the TAM queries the TEEP Agent 265 for supported commands offered by the SUIT manifest 266 implementation. 268 Further values may be added in the future via IANA registration. 270 CIPHER_SUITE The CIPHER_SUITE field lists the ciphersuite(s) 271 supported by the TAM. Details about the ciphersuite encoding can 272 be found in Section 5. 274 NONCE NONCE is an optional field used for ensuring the refreshness 275 of the Entity Attestation Token (EAT) contained in the response. 277 VERSION The VERSION field lists the version(s) supported by the TAM. 278 For this version of the specification this field can be omitted. 280 OCSP_DATA The OCSP_DATA field contains a list of OCSP stapling data 281 respectively for the TAM certificate and each of the CA 282 certificates up to the root certificate. The TAM provides OCSP 283 data so that the TEEP Agent can validate the status of the TAM 284 certificate chain without making its own external OCSP service 285 call. OCSP data MUST be conveyed as a DER-encoded OCSP response 286 (using the ASN.1 type OCSPResponse defined in [RFC2560]). The use 287 of OCSP is optional to implement for both the TAM and the TEEP 288 Agent. A TAM can query the TEEP Agent for the support of this 289 functionality via the capability discovery exchange, as described 290 above. 292 4.2. QueryResponse 293 ta_id = ( 294 Vendor_ID = bstr, 295 Class_ID = bstr, 296 Device_ID = bstr, 297 * $$extensions 298 ) 300 ext_info = int 302 QueryResponse = ( 303 TYPE : int, 304 TOKEN : bstr, 305 ? SELECTED_CIPHER_SUITE : suite, 306 ? SELECTED_VERSION : version, 307 ? EAT : bstr, 308 ? TA_LIST : [+ta_id], 309 ? EXT_LIST : [+ext_info], 310 * $$extensions 311 ) 313 The QueryResponse message is signed and encrypted by the TEEP Agent 314 and returned to the TAM. It has the following fields: 316 TYPE TYPE = 2 corresponds to a QueryResponse message sent from the 317 TEEP Agent to the TAM. 319 TOKEN The value in the TOKEN field is used to match requests to 320 responses. The value MUST correspond to the value received with 321 the QueryRequest. 323 SELECTED_CIPHER_SUITE The SELECTED_CIPHER_SUITE field indicates the 324 selected ciphersuite. Details about the ciphersuite encoding can 325 be found in Section 5. 327 SELECTED_VERSION The SELECTED_VERSION field indicates the protocol 328 version selected by the TEEP Agent. 330 EAT The EAT field contains an Entity Attestation Token following the 331 encoding defined in [I-D.ietf-rats-eat]. 333 TA_LIST The TA_LIST field enumerates the trusted applications 334 installed on the device in form of ta_ids, i.e., a vendor id/class 335 id/device id triple. 337 EXT_LIST The EXT_LIST field lists the supported extensions. This 338 document does not define any extensions. 340 4.3. TrustedAppInstall 342 TrustedAppInstall = ( 343 TYPE : int, 344 TOKEN : bstr, 345 ? MANIFEST_LIST : [+ SUIT_Outer_Wrapper], 346 * $$extensions 347 ) 349 The TrustedAppInstall message is MACed and encrypted by the TAM and 350 has the following fields: 352 TYPE TYPE = 3 corresponds to a TrustedAppInstall message sent from 353 the TAM to the TEEP Agent. In case of successful processing, an 354 Success message is returned by the TEEP Agent. In case of an 355 error, an Error message is returned. Note that the 356 TrustedAppInstall message is used for initial TA installation but 357 also for TA updates. 359 TOKEN The value in the TOKEN field is used to match requests to 360 responses. 362 TA The MANIFEST_LIST field is used to convey one or multiple SUIT 363 manifests. A manifest is a bundle of metadata about the trusted 364 app, where to find the code, the devices to which it applies, and 365 cryptographic information protecting the manifest. The manifest 366 may also convey personalization data. TA binaries and 367 personalization data is typically signed and encrypted by the SP. 368 Other combinations are, however, possible as well. For example, 369 it is also possible for the TAM to sign and encrypt the 370 personalization data and to let the SP sign and/or encrypt the TA 371 binary. 373 4.4. TrustedAppDelete 375 TrustedAppDelete = ( 376 TYPE : int, 377 TOKEN : bstr, 378 ? TA_LIST : [+ta_id], 379 * $$extensions 380 ) 382 The TrustedAppDelete message is MACed and encrypted by the TAM and 383 has the following fields: 385 TYPE TYPE = 4 corresponds to a TrustedAppDelete message sent from 386 the TAM to the TEEP Agent. In case of successful processing, an 387 Success message is returned by the TEEP Agent. In case of an 388 error, an Error message is returned. 390 TOKEN The value in the TOKEN field is used to match requests to 391 responses. 393 TA_LIST The TA_LIST field enumerates the TAs to be deleted. 395 4.5. Success 397 Success = ( 398 TYPE : int, 399 TOKEN : bstr, 400 ? MSG : tstr, 401 * $$extensions 402 ) 404 The Success message is MACed and encrypted by the TEEP Agent and has 405 the following fields: 407 TYPE TYPE = 5 corresponds to a Error message sent from the TEEP 408 Agent to the TAM. 410 TOKEN The value in the TOKEN field is used to match requests to 411 responses. 413 MSG The MSG field contains optional diagnostics information encoded 414 in UTF-8 [RFC3629] returned by the TEEP Agent. 416 4.6. Error 418 Error = ( 419 TYPE : int, 420 TOKEN : bstr, 421 ERR_CODE : int, 422 ? ERR_MSG : tstr, 423 ? CIPHER_SUITE : [+suite], 424 ? VERSION : [+version], 425 * $$extensions 426 ) 428 If possible, the Error message is MACed and encrypted by the TEEP 429 Agent. Unprotected Error messages MUST be handled with care by the 430 TAM due to possible downgrading attacks. It has the following 431 fields: 433 TYPE TYPE = 6 corresponds to a Error message sent from the TEEP 434 Agent to the TAM. 436 TOKEN The value in the TOKEN field is used to match requests to 437 responses. 439 ERR_CODE The ERR_CODE field is populated with values listed in a 440 registry (with the initial set of error codes listed below). Only 441 selected messages are applicable to each message. 443 ERR_MSG The ERR_MSG message is a human-readable diagnostic message 444 that MUST be encoded using UTF-8 [RFC3629] using Net-Unicode form 445 [RFC5198]. 447 VERSION The VERSION field enumerates the protocol version(s) 448 supported by the TEEP Agent. This field is optional but MUST be 449 returned with the ERR_UNSUPPORTED_MSG_VERSION error message. 451 CIPHER_SUITE The CIPHER_SUITE field lists the ciphersuite(s) 452 supported by the TEEP Agent. This field is optional but MUST be 453 returned with the ERR_UNSUPPORTED_CRYPTO_ALG error message. 455 This specification defines the following initial error messages. 456 Additional error code can be registered with IANA. 458 ERR_ILLEGAL_PARAMETER The TEEP Agent sends this error message when a 459 request contains incorrect fields or fields that are inconsistent 460 with other fields. 462 ERR_UNSUPPORTED_EXTENSION The TEEP Agent sends this error message 463 when it recognizes an unsupported extension or unsupported 464 message. 466 ERR_REQUEST_SIGNATURE_FAILED The TEEP Agent sends this error message 467 when it fails to verify the signature of the message. 469 ERR_UNSUPPORTED_MSG_VERSION The TEEP Agent receives a message but 470 does not support the indicated version. 472 ERR_UNSUPPORTED_CRYPTO_ALG The TEEP Agent receives a request message 473 encoded with an unsupported cryptographic algorithm. 475 ERR_BAD_CERTIFICATE The TEEP Agent returns this error when 476 processing of a certificate failed. For diagnosis purposes it is 477 RECOMMMENDED to include information about the failing certificate 478 in the error message. 480 ERR_UNSUPPORTED_CERTIFICATE The TEEP Agent returns this error when a 481 certificate was of an unsupported type. 483 ERR_CERTIFICATE_REVOKED The TEEP Agent returns this error when a 484 certificate was revoked by its signer. 486 ERR_CERTIFICATE_EXPIRED The TEEP Agent returns this error when a 487 certificate has expired or is not currently valid. 489 ERR_INTERNAL_ERROR The TEEP Agent returns this error when a 490 miscellaneous internal error occurred while processing the 491 request. 493 ERR_RESOURCE_FULL This error is reported when a device resource 494 isn't available anymore, such as storage space is full. 496 ERR_TA_NOT_FOUND This error will occur when the target TA does not 497 exist. This error may happen when the TAM has stale information 498 and tries to delete a TA that has already been deleted. 500 ERR_TA_ALREADY_INSTALLED While installing a TA, a TEE will return 501 this error if the TA has already been installed. 503 ERR_TA_UNKNOWN_FORMAT The TEEP Agent returns this error when it does 504 not recognize the format of the TA binary. 506 ERR_TA_DECRYPTION_FAILED The TEEP Agent returns this error when it 507 fails to decrypt the TA binary. 509 ERR_TA_DECOMPRESSION_FAILED The TEEP Agent returns this error when 510 it fails to decompress the TA binary. 512 ERR_MANIFEST_PROCESSING_FAILED The TEEP Agent returns this error 513 when manifest processing failures occur that are less specific 514 than ERR_TA_UNKNOWN_FORMAT, ERR_TA_UNKNOWN_FORMAT, and 515 ERR_TA_DECOMPRESSION_FAILED. 517 ERR_PD_PROCESSING_FAILED The TEEP Agent returns this error when it 518 fails to process the provided personalization data. 520 5. Ciphersuites 522 A ciphersuite consists of an AEAD algorithm, a HMAC algorithm, and a 523 signature algorithm. Each ciphersuite is identified with an integer 524 value, which corresponds to an IANA registered ciphersuite. This 525 document specifies two ciphersuites. 527 Value | Ciphersuite 528 ------+------------------------------------------------ 529 0 | AES-CCM-16-64-128, HMAC 256/256, X25519, EdDSA 530 1 | AES-CCM-16-64-128, HMAC 256/256, P-256, ES256 532 6. Security Consideration 534 This section summarizes the security considerations discussed in this 535 specification: 537 Cryptographic Algorithms This specification relies on the 538 cryptographic algorithms provided by the security wrappers JOSE 539 and COSE, respectively. A companion document makes algorithm 540 recommendations but this document is written in an algorithm- 541 agnostic way. TEEP protocol messages exchanged between the TAM 542 and the TEEP Agent are protected using JWS and JWE (for JSON- 543 encoded messages) and COSE (for CBOR-encoded messages). Public 544 key based authentication is used to by the TEEP Agent to 545 authenticate the TAM and vice versa. 547 Attestation A TAM may rely on the attestation information provided 548 by the TEEP Agent and the Entity Attestation Token is re-used to 549 convey this information. To sign the Entity Attestation Token it 550 is necessary for the device to possess a public key (usually in 551 the form of a certificate) along with the corresponding private 552 key. Depending on the properties of the attestation mechanism it 553 is possible to uniquely identify a device based on information in 554 the attestation information or in the certificate used to sign the 555 attestation token. This uniqueness may raise privacy concerns. 556 To lower the privacy implications the TEEP Agent MUST present its 557 attestation information only to an authenticated and authorized 558 TAM. 560 TA Binaries TA binaries are provided by the SP.It is the 561 responsibility of the TAM to relay only verified TAs from 562 authorized SPs. Delivery of that TA to the TEEP Agent is then the 563 responsibility of the TAM and the TEEP Broker, using the security 564 mechanisms provided by the TEEP protocol. To protect the TA 565 binary the SUIT manifest is re-used and it offers a varity of 566 security features, including digitial signatures and symmetric 567 encryption. 569 Personalization Data An SP or a TAM can supply personalization data 570 along with a TA. This data is also protected by a SUIT manifest. 571 The personalization data may be itself is (or can be) opaque to 572 the TAM. 574 TEEP Broker The TEEP protocol relies on the TEEP Broker to relay 575 messages between the TAM and the TEEP Agent. When the TEEP Broker 576 is compromised it can drop messages, delay the delivery of 577 messages, and replay messages but it cannot modify those messages. 578 (A replay would be, however, detected by the TEEP Agent.) A 579 compromised TEEP Broker could reorder messages in an attempt to 580 install an old version of a TA. Information in the manifest 581 ensures that the TEEP Agents are protected against such 582 downgrading attacks based on features offered by the manifest 583 itself. 585 CA Compromise The QueryRequest message from a TAM to the TEEP Agent 586 may include OCSP stapling data for the TAM's signer certificate 587 and for intermediate CA certificates up to the root certificate so 588 that the TEEP Agent can verify the certificate's revocation 589 status. 591 A certificate revocation status check on a TA signer certificate 592 is OPTIONAL by a TEEP Agent. A TAM is responsible for vetting a 593 TA and before distributing them to TEEP Agents. TEEP Agents will 594 trust a TA signer certificate's validation status done by a TAM. 596 CA Compromise The CA issuing certificates to a TAM or an SP may get 597 compromised. A compromised intermediate CA certificates can be 598 detected by a TEEP Agent by using OCSP information, assuming the 599 revocation information is available. Additionally, it is 600 RECOMMENDED to provide a way to update the trust anchor store used 601 by the device, for example using a firmware update mechanism. 603 If the CA issuing certificates to devices gets compromised then 604 these devices might be rejected by a TAM, if revocation is 605 available to the TAM. 607 Compromised TAM The TEEP Agent SHOULD use OCSP information to verify 608 the validity of the TAM-provided certificate (as well as the 609 validity of intermediate CA certificates). The integrity and the 610 accuracy of the clock within the TEE determines the ability to 611 determine an expired or revoked certificate since OCSP stapling 612 includes signature generation time, certificate validity dates are 613 compared to the current time. 615 7. IANA Considerations 617 7.1. Media Type Registration 619 IANA is requested to assign a media type for application/teep+json. 621 Type name: application 623 Subtype name: teep+json 625 Required parameters: none 627 Optional parameters: none 628 Encoding considerations: Same as encoding considerations of 629 application/json as specified in Section 11 of [RFC7159] 631 Security considerations: See Security Considerations Section of this 632 document. 634 Interoperability considerations: Same as interoperability 635 considerations of application/json as specified in [RFC7159] 637 Published specification: This document. 639 Applications that use this media type: TEEP protocol implementations 641 Fragment identifier considerations: N/A 643 Additional information: 645 Deprecated alias names for this type: N/A 647 Magic number(s): N/A 649 File extension(s): N/A 651 Macintosh file type code(s): N/A 653 Person to contact for further information: teep@ietf.org 655 Intended usage: COMMON 657 Restrictions on usage: none 659 Author: See the "Authors' Addresses" section of this document 661 Change controller: IETF 663 IANA is requested to assign a media type for application/teep+cbor. 665 Type name: application 667 Subtype name: teep+cbor 669 Required parameters: none 671 Optional parameters: none 673 Encoding considerations: Same as encoding considerations of 674 application/cbor 676 Security considerations: See Security Considerations Section of this 677 document. 679 Interoperability considerations: Same as interoperability 680 considerations of application/cbor as specified in [RFC7049] 682 Published specification: This document. 684 Applications that use this media type: TEEP protocol implementations 686 Fragment identifier considerations: N/A 688 Additional information: 690 Deprecated alias names for this type: N/A 692 Magic number(s): N/A 694 File extension(s): N/A 696 Macintosh file type code(s): N/A 698 Person to contact for further information: teep@ietf.org 700 Intended usage: COMMON 702 Restrictions on usage: none 704 Author: See the "Authors' Addresses" section of this document 706 Change controller: IETF 708 7.2. Error Code Registry 710 IANA is also requested to create a new registry for the error codes 711 defined in Section 4. 713 Registration requests are evaluated after a three-week review period 714 on the teep-reg-review@ietf.org mailing list, on the advice of one or 715 more Designated Experts [RFC8126]. However, to allow for the 716 allocation of values prior to publication, the Designated Experts may 717 approve registration once they are satisfied that such a 718 specification will be published. 720 Registration requests sent to the mailing list for review should use 721 an appropriate subject (e.g., "Request to register an error code: 722 example"). Registration requests that are undetermined for a period 723 longer than 21 days can be brought to the IESG's attention (using the 724 iesg@ietf.org mailing list) for resolution. 726 Criteria that should be applied by the Designated Experts includes 727 determining whether the proposed registration duplicates existing 728 functionality, whether it is likely to be of general applicability or 729 whether it is useful only for a single extension, and whether the 730 registration description is clear. 732 IANA must only accept registry updates from the Designated Experts 733 and should direct all requests for registration to the review mailing 734 list. 736 7.3. Ciphersuite Registry 738 IANA is also requested to create a new registry for ciphersuites, as 739 defined in Section 5. 741 8. References 743 8.1. Normative References 745 [I-D.ietf-rats-eat] 746 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 747 O'Donoghue, "The Entity Attestation Token (EAT)", draft- 748 ietf-rats-eat-01 (work in progress), July 2019. 750 [I-D.ietf-suit-manifest] 751 Moran, B., Tschofenig, H., and H. Birkholz, "A Concise 752 Binary Object Representation (CBOR)-based Serialization 753 Format for the Software Updates for Internet of Things 754 (SUIT) Manifest", draft-ietf-suit-manifest-02 (work in 755 progress), November 2019. 757 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 758 Requirement Levels", BCP 14, RFC 2119, 759 DOI 10.17487/RFC2119, March 1997, 760 . 762 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 763 Adams, "X.509 Internet Public Key Infrastructure Online 764 Certificate Status Protocol - OCSP", RFC 2560, 765 DOI 10.17487/RFC2560, June 1999, 766 . 768 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 769 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 770 2003, . 772 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 773 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 774 . 776 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 777 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 778 . 780 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 781 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 782 October 2013, . 784 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 785 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 786 2014, . 788 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 789 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 790 2015, . 792 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 793 RFC 7516, DOI 10.17487/RFC7516, May 2015, 794 . 796 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 797 DOI 10.17487/RFC7517, May 2015, 798 . 800 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 801 DOI 10.17487/RFC7518, May 2015, 802 . 804 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 805 RFC 8152, DOI 10.17487/RFC8152, July 2017, 806 . 808 8.2. Informative References 810 [I-D.ietf-cbor-cddl] 811 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 812 definition language (CDDL): a notational convention to 813 express CBOR and JSON data structures", draft-ietf-cbor- 814 cddl-08 (work in progress), March 2019. 816 [I-D.ietf-teep-architecture] 817 Pei, M., Tschofenig, H., Wheeler, D., Atyeo, A., and D. 818 Liu, "Trusted Execution Environment Provisioning (TEEP) 819 Architecture", draft-ietf-teep-architecture-04 (work in 820 progress), December 2019. 822 [I-D.ietf-teep-opentrustprotocol] 823 Pei, M., Atyeo, A., Cook, N., Yoo, M., and H. Tschofenig, 824 "The Open Trust Protocol (OTrP)", draft-ietf-teep- 825 opentrustprotocol-03 (work in progress), May 2019. 827 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 828 Writing an IANA Considerations Section in RFCs", BCP 26, 829 RFC 8126, DOI 10.17487/RFC8126, June 2017, 830 . 832 Appendix A. Acknowledgements 834 This work is based on the initial version of OTrP 835 [I-D.ietf-teep-opentrustprotocol] and hence credits go to those who 836 have contributed to it. 838 We would like to thank Eve Schooler for the suggestion of the 839 protocol name. 841 Appendix B. Contributors 843 We would like to thank the following individuals for their 844 contributions to an earlier version of this specification. 846 - Brian Witten 847 Symantec 848 brian_witten@symantec.com 850 - Tyler Kim 851 Solacia 852 tylerkim@iotrust.kr 854 - Nick Cook 855 Arm Ltd. 856 nicholas.cook@arm.com 858 - Minho Yoo 859 IoTrust 860 minho.yoo@iotrust.kr 862 Authors' Addresses 864 Hannes Tschofenig 865 Arm Ltd. 866 110 Fulbourn Rd 867 Cambridge, CB1 9NJ 868 Great Britain 870 Email: hannes.tschofenig@arm.com 872 Mingliang Pei 873 Broadcom 874 350 Ellis St 875 Mountain View, CA 94043 876 USA 878 Email: mingliang.pei@broadcom.com 880 David Wheeler 881 Intel 882 US 884 Email: david.m.wheeler@intel.com 886 Dave Thaler 887 Microsoft 888 US 890 Email: dthaler@microsoft.com