idnits 2.17.1 draft-tschofenig-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 (November 4, 2019) is 1628 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 698, but no explicit reference was found in the text == Unused Reference: 'RFC7517' is defined on line 722, but no explicit reference was found in the text == Unused Reference: 'RFC7518' is defined on line 726, 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-01 ** 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-03 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEEP M. Pei 3 Internet-Draft Symantec 4 Intended status: Standards Track H. Tschofenig 5 Expires: May 7, 2020 Arm Ltd. 6 D. Wheeler 7 Intel 8 November 4, 2019 10 Trusted Execution Environment Provisioning (TEEP) Protocol 11 draft-tschofenig-teep-protocol-00 13 Abstract 15 This document specifies a protocol that installs, updates, and 16 deletes Trusted Applications (TAs) in a device with a Trusted 17 Execution Environment (TEE). Due to its function it is called 18 "Trusted Execution Environment Provisioning (TEEP) Protocol", which 19 provides interoperability for mantaining the lifecycle of TAs. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 7, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 57 3. Message Overview . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Detailed Messages Specification . . . . . . . . . . . . . . . 4 59 5. Security Consideration . . . . . . . . . . . . . . . . . . . 11 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 62 7.1. Normative References . . . . . . . . . . . . . . . . . . 15 63 7.2. Informative References . . . . . . . . . . . . . . . . . 17 64 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17 65 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 17 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 68 1. Introduction 70 The Trusted Execution Environment (TEE) concept has been designed to 71 separate a regular operating system, also referred as a Rich 72 Execution Environment (REE), from security-sensitive applications. 73 In an TEE ecosystem, different device vendors may use different 74 operating systems in the REE and may use different types of TEEs. 75 When application providers or device administrators use Trusted 76 Application Managers (TAMs) to install, update, and delete Trusted 77 Applications (TAs) on a wide range of devices with potentially 78 different TEEs then an interoperability need arises. 80 This document specifies the protocol for communicating between a TAM 81 and a TEEP Agent, involving a TEEP Broker. 83 The Trusted Execution Environment Provisioning (TEEP) architecture 84 document [I-D.ietf-teep-architecture] has set to provide a design 85 guidance for such an interoperable protocol and introduces the 86 necessary terminology. Note that the term Trusted Application may 87 include more than code; it may also include configuration data and 88 keys needed by the TA to operate correctly. 90 2. Requirements Language 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 This specification re-uses the terminology defined in 97 [I-D.ietf-teep-architecture]. 99 3. Message Overview 101 The TEEP protocol consists of a couple of messages exchanged between 102 a TAM and a TEEP Agent via a TEEP Broker. The messages are encoded 103 either in JSON or CBOR and designed to provide end-to-end security. 104 TEEP protocol messages are signed and/or encrypted by the endpoints, 105 i.e., the TAM and the TEEP Agent, but trusted applications may as 106 well be encrypted and signed by the service provider. The TEEP 107 protocol not only re-use JSON and CBOR but also the respective 108 security wrappers, namely JOSE (JWS [RFC7515] and JWE [RFC7516], to 109 be more specific) and COSE [RFC8152]. Furthermore, for attestation 110 the Entity Attestation Token (EAT) [I-D.ietf-rats-eat] and for 111 software updates the SUIT manifest format [I-D.ietf-suit-manifest] is 112 re-used. 114 This specification defines six messages. 116 A TAM queries a device's current state with a QueryRequest message. 117 A TEEP Agent will, after authenticating and authorizing the request, 118 report attestation information, list all TAs, and provide information 119 about supported algorithms and extensions in a QueryResponse message. 120 An error message is returned if the request could not be processed. 121 A TAM will process the QueryResponse message and determine whether 122 subsequent message exchanges to install, update, or delete trusted 123 applications shall be initiated. 125 +------------+ +-------------+ 126 | TAM | |TEEP Agent | 127 +------------+ +-------------+ 129 QueryRequest -------> 131 QueryResponse 133 <------- or 135 Error 137 With the TrustedAppInstall message a TAM can instruct a TEEP Agent to 138 install a TA. The TEEP Agent will process the message, determine 139 whether the TAM is authorized and whether the TA has been signed by 140 an authorized SP. In addition to the binary, the TAM may also 141 provide personalization data. If the TrustedAppInstall message was 142 processed successfully then a Success message is returned to the TAM, 143 an Error message otherwise. 145 +------------+ +-------------+ 146 | TAM | |TEEP Agent | 147 +------------+ +-------------+ 149 TrustedAppInstall ----> 151 Success 153 <---- or 155 Error 157 With the TrustedAppDelete message a TAM can instruct a TEEP Agent to 158 delete one or multiple TA(s). A Success message is returned when the 159 operation has been completed successfully, and an Error message 160 otherwise. 162 +------------+ +-------------+ 163 | TAM | |TEEP Agent | 164 +------------+ +-------------+ 166 TrustedAppDelete ----> 168 Success 170 <---- or 172 Error 174 4. Detailed Messages Specification 176 For a CBOR-based encoding the following security wrapper is used 177 (described in CDDL format [I-D.ietf-cbor-cddl]). 179 Outer_Wrapper = { 180 msg-authenc-wrapper => bstr .cbor 181 Msg_AuthEnc_Wrapper / nil, 182 teep-message => (QueryRequest / 183 QueryResponse / 184 TrustedAppInstall / 185 TrustedAppDelete / 186 Error / 187 Success ), 188 } 190 msg-authenc-wrapper = 1 191 teep-message = 2 193 Msg_AuthEnc_Wrapper = [ * (COSE_Mac_Tagged / 194 COSE_Sign_Tagged / 195 COSE_Mac0_Tagged / 196 COSE_Sign1_Tagged)] 198 A future version of this specification will also describe the 199 security wrapper for JSON (in CDDL format). 201 suite = int 203 version = int 205 data_items = ( 206 attestation: 1, 207 ta: 2, 208 ext: 3 209 ) 211 QueryRequest = ( 212 TYPE : int, 213 TOKEN : bstr, 214 REQUEST : [+data_items], 215 ? CIPHER_SUITE : [+suite], 216 ? NONCE : bstr, 217 ? VERSION : [+version], 218 ? OCSP_DATA : bstr, 219 * $$extensions 220 ) 222 A QueryRequest message is signed by the TAM and has the following 223 fields: 225 TYPE TYPE = 1 corresponds to a QueryRequest message sent from the 226 TAM to the TEEP Agent. 228 TOKEN The value in the TOKEN field is used to match requests to 229 responses. 231 REQUEST The REQUEST field indicates what information the TAM 232 requests from the TEEP Agent in form of a list of integer values. 233 Each integer value corresponds to an IANA registered information 234 element. This specification defines the initial set of 235 information elements. With 'attestation' (1) the TAM requests the 236 TEEP Agent to return an EAT entity attestation token in the 237 response, with 'ta' (2) the TAM wants to query the TEEP Agent for 238 all installed TAs, and with 'ext' (3) the TAM wants to query the 239 TEEP Agent for supported extensions. Further values may be added 240 in the future via IANA registration. 242 CIPHER_SUITE The CIPHER_SUITE field lists the ciphersuite(s) 243 supported by the TAM. 245 NONCE NONCE is an optional field used for ensuring the refreshness 246 of the Entity Attestation Token (EAT) contained in the response. 248 VERSION The VERSION field lists the version(s) supported by the TAM. 249 For this version of the specification this field can be omitted. 251 OCSP_DATA The OCSP_DATA field contains a list of OCSP stapling data 252 respectively for the TAM certificate and each of the CA 253 certificates up to the root certificate. The TAM provides OCSP 254 data so that the TEEP Agent can validate the status of the TAM 255 certificate chain without making its own external OCSP service 256 call. 258 ta_id = ( 259 Vendor_ID = bstr, 260 Class_ID = bstr, 261 Device_ID = bstr, 262 * $$extensions 263 ) 265 ext_info = int 267 QueryResponse = ( 268 TYPE : int, 269 TOKEN : bstr, 270 ? SELECTED_CIPHER_SUITE : suite, 271 ? SELECTED_VERSION : version, 272 ? EAT : bstr, 273 ? TA_LIST : [+ta_id], 274 ? EXT_LIST : [+ext_info], 275 * $$extensions 276 ) 278 The QueryResponse message is signed and encrypted by the TEEP Agent 279 and returned to the TAM. It has the following fields: 281 TYPE TYPE = 2 corresponds to a QueryResponse message sent from the 282 TEEP Agent to the TAM. 284 TOKEN The value in the TOKEN field is used to match requests to 285 responses. The value MUST correspond to the value received with 286 the QueryRequest. 288 SELECTED_CIPHER_SUITE The SELECTED_CIPHER_SUITE field indicates the 289 selected ciphersuite. 291 SELECTED_VERSION The SELECTED_VERSION field indicates the protocol 292 version selected by the TEEP Agent. 294 EAT The EAT field contains an Entity Attestation Token following the 295 encoding defined in [I-D.ietf-rats-eat]. 297 TA_LIST The TA_LIST field enumerates the trusted applications 298 installed on the device in form of ta_ids, i.e., a vendor id/class 299 id/device id triple. 301 EXT_LIST The EXT_LIST field lists the supported extensions. This 302 document does not define any extensions. 304 TrustedAppInstall = ( 305 TYPE : int, 306 TOKEN : bstr, 307 ? TA : [+SUIT_Outer_Wrapper], 308 * $$extensions 309 ) 311 The TrustedAppInstall message is MACed and encrypted by the TAM and 312 has the following fields: 314 TYPE TYPE = 3 corresponds to a TrustedAppInstall message sent from 315 the TAM to the TEEP Agent. In case of successful processing, an 316 Success message is returned by the TEEP Agent. In case of an 317 error, an Error message is returned. Note that the 318 TrustedAppInstall message is used for initial TA installation but 319 also for TA updates. 321 TOKEN The value in the TOKEN field is used to match requests to 322 responses. 324 TA The TA field is used to convey one or multiple SUIT manifests. 325 The SUIT manifest contains the code for the trusted app but may 326 also convey personalization data. TA binaries and personalization 327 data is often signed and encrypted by the SP. Other combinations 328 are, however, possible as well. For example, it is also possible 329 for the TAM to sign and encrypt the personalization data and to 330 let the SP sign and/or encrypt the TA binary. 332 TrustedAppDelete = ( 333 TYPE : int, 334 TOKEN : bstr, 335 ? TA_LIST : [+ta_id], 336 * $$extensions 337 ) 339 The TrustedAppDelete message is MACed and encrypted by the TAM and 340 has the following fields: 342 TYPE TYPE = 4 corresponds to a TrustedAppDelete message sent from 343 the TAM to the TEEP Agent. In case of successful processing, an 344 Success message is returned by the TEEP Agent. In case of an 345 error, an Error message is returned. 347 TOKEN The value in the TOKEN field is used to match requests to 348 responses. 350 TA_LIST The TA_LIST field enumerates the TAs to be deleted. 352 Success = ( 353 TYPE : int, 354 TOKEN : bstr, 355 ? MSG : tstr, 356 * $$extensions 357 ) 359 The Success message is MACed and encrypted by the TEEP Agent and has 360 the following fields: 362 TYPE TYPE = 5 corresponds to a Error message sent from the TEEP 363 Agent to the TAM. 365 TOKEN The value in the TOKEN field is used to match requests to 366 responses. 368 MSG The MSG field contains optional diagnostics information encoded 369 in UTF-8 [RFC3629] returned by the TEEP Agent. 371 Error = ( 372 TYPE : int, 373 TOKEN : bstr, 374 ERR_CODE : int, 375 ? ERR_MSG : tstr, 376 ? CIPHER_SUITE : [+suite], 377 ? VERSION : [+version], 378 * $$extensions 379 ) 381 If possible, the Error message is MACed and encrypted by the TEEP 382 Agent. Unprotected Error messages MUST be handled with care by the 383 TAM due to possible downgrading attacks. It has the following 384 fields: 386 TYPE TYPE = 6 corresponds to a Error message sent from the TEEP 387 Agent to the TAM. 389 TOKEN The value in the TOKEN field is used to match requests to 390 responses. 392 ERR_CODE The ERR_CODE field is populated with values listed in a 393 registry (with the initial set of error codes listed below). Only 394 selected messages are applicable to each message. 396 ERR_MSG The ERR_MSG message is a human-readable diagnostic message 397 that MUST be encoded using UTF-8 [RFC3629] using Net-Unicode form 398 [RFC5198]. 400 VERSION The VERSION field enumerates the protocol version(s) 401 supported by the TEEP Agent. This field is optional but MUST be 402 returned with the ERR_UNSUPPORTED_MSG_VERSION error message. 404 CIPHER_SUITE The CIPHER_SUITE field lists the ciphersuite(s) 405 supported by the TEEP Agent. This field is optional but MUST be 406 returned with the ERR_UNSUPPORTED_CRYPTO_ALG error message. 408 This specification defines the following initial error messages. 409 Additional error code can be registered with IANA. 411 ERR_ILLEGAL_PARAMETER The TEEP Agent sends this error message when a 412 request contains incorrect fields or fields that are inconsistent 413 with other fields. 415 ERR_UNSUPPORTED_EXTENSION The TEEP Agent sends this error message 416 when it recognizes an unsupported extension or unsupported 417 message. 419 ERR_REQUEST_SIGNATURE_FAILED The TEEP Agent sends this error message 420 when it fails to verify the signature of the message. 422 ERR_UNSUPPORTED_MSG_VERSION The TEEP Agent receives a message but 423 does not support the indicated version. 425 ERR_UNSUPPORTED_CRYPTO_ALG The TEEP Agent receives a request message 426 encoded with an unsupported cryptographic algorithm. 428 ERR_BAD_CERTIFICATE The TEEP Agent returns this error when 429 processing of a certificate failed. For diagnosis purposes it is 430 RECOMMMENDED to include information about the failing certificate 431 in the error message. 433 ERR_UNSUPPORTED_CERTIFICATE The TEEP Agent returns this error when a 434 certificate was of an unsupported type. 436 ERR_CERTIFICATE_REVOKED The TEEP Agent returns this error when a 437 certificate was revoked by its signer. 439 ERR_CERTIFICATE_EXPIRED The TEEP Agent returns this error when a 440 certificate has expired or is not currently valid. 442 ERR_INTERNAL_ERROR The TEEP Agent returns this error when a 443 miscellaneous internal error occurred while processing the 444 request. 446 ERR_RESOURCE_FULL This error is reported when a device resource 447 isn't available anymore, such as storage space is full. 449 ERR_TA_NOT_FOUND This error will occur when the target TA does not 450 exist. This error may happen when the TAM has stale information 451 and tries to delete a TA that has already been deleted. 453 ERR_TA_ALREADY_INSTALLED While installing a TA, a TEE will return 454 this error if the TA has already been installed. 456 ERR_TA_UNKNOWN_FORMAT The TEEP Agent returns this error when it does 457 not recognize the format of the TA binary. 459 ERR_TA_DECRYPTION_FAILED The TEEP Agent returns this error when it 460 fails to decrypt the TA binary. 462 ERR_TA_DECOMPRESSION_FAILED The TEEP Agent returns this error when 463 it fails to decompress the TA binary. 465 ERR_MANIFEST_PROCESSING_FAILED The TEEP Agent returns this error 466 when manifest processing failures occur that are less specific 467 than ERR_TA_UNKNOWN_FORMAT, ERR_TA_UNKNOWN_FORMAT, and 468 ERR_TA_DECOMPRESSION_FAILED. 470 ERR_PD_PROCESSING_FAILED The TEEP Agent returns this error when it 471 fails to process the provided personalization data. 473 5. Security Consideration 475 This section summarizes the security considerations discussed in this 476 specification: 478 Cryptographic Algorithms This specification relies on the 479 cryptographic algorithms provided by the security wrappers JOSE 480 and COSE, respectively. A companion document makes algorithm 481 recommendations but this document is written in an algorithm- 482 agnostic way. TEEP protocol messages exchanged between the TAM 483 and the TEEP Agent are protected using JWS and JWE (for JSON- 484 encoded messages) and COSE (for CBOR-encoded messages). Public 485 key based authentication is used to by the TEEP Agent to 486 authenticate the TAM and vice versa. 488 Attestation A TAM may rely on the attestation information provided 489 by the TEEP Agent and the Entity Attestation Token is re-used to 490 convey this information. To sign the Entity Attestation Token it 491 is necessary for the device to possess a public key (usually in 492 the form of a certificate) along with the corresponding private 493 key. Depending on the properties of the attestation mechanism it 494 is possible to uniquely identify a device based on information in 495 the attestation information or in the certificate used to sign the 496 attestation token. This uniqueness may raise privacy concerns. 498 To lower the privacy implications the TEEP Agent MUST present its 499 attestation information only to an authenticated and authorized 500 TAM. 502 TA Binaries TA binaries are provided by the SP.It is the 503 responsibility of the TAM to relay only verified TAs from 504 authorized SPs. Delivery of that TA to the TEEP Agent is then the 505 responsibility of the TAM and the TEEP Broker, using the security 506 mechanisms provided by the TEEP protocol. To protect the TA 507 binary the SUIT manifest is re-used and it offers a varity of 508 security features, including digitial signatures and symmetric 509 encryption. 511 Personalization Data An SP or a TAM can supply personalization data 512 along with a TA. This data is also protected by a SUIT manifest. 513 The personalization data may be itself is (or can be) opaque to 514 the TAM. 516 TEEP Broker The TEEP protocol relies on the TEEP Broker to relay 517 messages between the TAM and the TEEP Agent. When the TEEP Broker 518 is compromised it can drop messages, delay the delivery of 519 messages, and replay messages but it cannot modify those messages. 520 (A replay would be, however, detected by the TEEP Agent.) A 521 compromised TEEP Broker could reorder messages in an attempt to 522 install an old version of a TA. Information in the manifest 523 ensures that the TEEP Agents are protected against such 524 downgrading attacks based on features offered by the manifest 525 itself. 527 CA Compromise The QueryRequest message from a TAM to the TEEP Agent 528 may include OCSP stapling data for the TAM's signer certificate 529 and for intermediate CA certificates up to the root certificate so 530 that the TEEP Agent can verify the certificate's revocation 531 status. 533 A certificate revocation status check on a TA signer certificate 534 is OPTIONAL by a TEEP Agent. A TAM is responsible for vetting a 535 TA and before distributing them to TEEP Agents. TEEP Agents will 536 trust a TA signer certificate's validation status done by a TAM. 538 CA Compromise The CA issuing certificates to a TAM or an SP may get 539 compromised. A compromised intermediate CA certificates can be 540 detected by a TEEP Agent by using OCSP information, assuming the 541 revocation information is available. Additionally, it is 542 RECOMMENDED to provide a way to update the trust anchor store used 543 by the device, for example using a firmware update mechanism. 545 If the CA issuing certificates to devices gets compromised then 546 these devices might be rejected by a TAM, if revocation is 547 available to the TAM. 549 Compromised TAM The TEEP Agent SHOULD use OCSP information to verify 550 the validity of the TAM-provided certificate (as well as the 551 validity of intermediate CA certificates). The integrity and the 552 accuracy of the clock within the TEE determines the ability to 553 determine an expired or revoked certificate since OCSP stapling 554 includes signature generation time, certificate validity dates are 555 compared to the current time. 557 6. IANA Considerations 559 There are two IANA requests: a media type and list of error codes. 561 IANA is requested to assign a media type for application/otrpv2+json. 563 Type name: application 565 Subtype name: teep+json 567 Required parameters: none 569 Optional parameters: none 571 Encoding considerations: Same as encoding considerations of 572 application/json as specified in Section 11 of [RFC7159] 574 Security considerations: See Security Considerations Section of this 575 document. 577 Interoperability considerations: Same as interoperability 578 considerations of application/json as specified in [RFC7159] 580 Published specification: This document. 582 Applications that use this media type: TEEP protocol implementations 584 Fragment identifier considerations: N/A 586 Additional information: 588 Deprecated alias names for this type: N/A 590 Magic number(s): N/A 592 File extension(s): N/A 593 Macintosh file type code(s): N/A 595 Person to contact for further information: teep@ietf.org 597 Intended usage: COMMON 599 Restrictions on usage: none 601 Author: See the "Authors' Addresses" section of this document 603 Change controller: IETF 605 IANA is requested to assign a media type for application/teep+cbor. 607 Type name: application 609 Subtype name: teep+cbor 611 Required parameters: none 613 Optional parameters: none 615 Encoding considerations: Same as encoding considerations of 616 application/cbor 618 Security considerations: See Security Considerations Section of this 619 document. 621 Interoperability considerations: Same as interoperability 622 considerations of application/cbor as specified in [RFC7049] 624 Published specification: This document. 626 Applications that use this media type: TEEP protocol implementations 628 Fragment identifier considerations: N/A 630 Additional information: 632 Deprecated alias names for this type: N/A 634 Magic number(s): N/A 636 File extension(s): N/A 638 Macintosh file type code(s): N/A 640 Person to contact for further information: teep@ietf.org 641 Intended usage: COMMON 643 Restrictions on usage: none 645 Author: See the "Authors' Addresses" section of this document 647 Change controller: IETF 649 IANA is also requested to create a new registry for the error codes 650 defined in Section 4. 652 Registration requests are evaluated after a three-week review period 653 on the teep-reg-review@ietf.org mailing list, on the advice of one or 654 more Designated Experts [RFC8126]. However, to allow for the 655 allocation of values prior to publication, the Designated Experts may 656 approve registration once they are satisfied that such a 657 specification will be published. 659 Registration requests sent to the mailing list for review should use 660 an appropriate subject (e.g., "Request to register an error code: 661 example"). Registration requests that are undetermined for a period 662 longer than 21 days can be brought to the IESG's attention (using the 663 iesg@ietf.org mailing list) for resolution. 665 Criteria that should be applied by the Designated Experts includes 666 determining whether the proposed registration duplicates existing 667 functionality, whether it is likely to be of general applicability or 668 whether it is useful only for a single extension, and whether the 669 registration description is clear. 671 IANA must only accept registry updates from the Designated Experts 672 and should direct all requests for registration to the review mailing 673 list. 675 7. References 677 7.1. Normative References 679 [I-D.ietf-rats-eat] 680 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 681 O'Donoghue, "The Entity Attestation Token (EAT)", draft- 682 ietf-rats-eat-01 (work in progress), July 2019. 684 [I-D.ietf-suit-manifest] 685 Moran, B., Tschofenig, H., and H. Birkholz, "SUIT CBOR 686 manifest serialisation format", draft-ietf-suit- 687 manifest-01 (work in progress), October 2019. 689 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 690 Requirement Levels", BCP 14, RFC 2119, 691 DOI 10.17487/RFC2119, March 1997, 692 . 694 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 695 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 696 2003, . 698 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 699 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 700 . 702 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 703 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 704 . 706 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 707 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 708 October 2013, . 710 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 711 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 712 2014, . 714 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 715 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 716 2015, . 718 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 719 RFC 7516, DOI 10.17487/RFC7516, May 2015, 720 . 722 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 723 DOI 10.17487/RFC7517, May 2015, 724 . 726 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 727 DOI 10.17487/RFC7518, May 2015, 728 . 730 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 731 RFC 8152, DOI 10.17487/RFC8152, July 2017, 732 . 734 7.2. Informative References 736 [I-D.ietf-cbor-cddl] 737 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 738 definition language (CDDL): a notational convention to 739 express CBOR and JSON data structures", draft-ietf-cbor- 740 cddl-08 (work in progress), March 2019. 742 [I-D.ietf-teep-architecture] 743 Pei, M., Tschofenig, H., Wheeler, D., Atyeo, A., and D. 744 Liu, "Trusted Execution Environment Provisioning (TEEP) 745 Architecture", draft-ietf-teep-architecture-03 (work in 746 progress), July 2019. 748 [I-D.ietf-teep-opentrustprotocol] 749 Pei, M., Atyeo, A., Cook, N., Yoo, M., and H. Tschofenig, 750 "The Open Trust Protocol (OTrP)", draft-ietf-teep- 751 opentrustprotocol-03 (work in progress), May 2019. 753 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 754 Writing an IANA Considerations Section in RFCs", BCP 26, 755 RFC 8126, DOI 10.17487/RFC8126, June 2017, 756 . 758 Appendix A. Acknowledgements 760 This work is based on the initial version of OTrP 761 [I-D.ietf-teep-opentrustprotocol] and hence credits go to those who 762 have contributed to it. 764 Appendix B. Contributors 766 We would like to thank the following individuals for their 767 contributions to an earlier version of this specification. 769 - Brian Witten 770 Symantec 771 brian_witten@symantec.com 773 - Tyler Kim 774 Solacia 775 tylerkim@iotrust.kr 777 - Nick Cook 778 Arm Ltd. 779 nicholas.cook@arm.com 781 - Minho Yoo 782 IoTrust 783 minho.yoo@iotrust.kr 785 Authors' Addresses 787 Mingliang Pei 788 Symantec 789 350 Ellis St 790 Mountain View, CA 94043 791 USA 793 Email: mingliang_pei@symantec.com 795 Hannes Tschofenig 796 Arm Ltd. 797 110 Fulbourn Rd 798 Cambridge, CB1 9NJ 799 Great Britain 801 Email: hannes.tschofenig@arm.com 803 David Wheeler 804 Intel 805 US 807 Email: david.m.wheeler@intel.com