idnits 2.17.1 draft-tschofenig-teep-otrp-v2-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 (July 8, 2019) is 1753 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 685, but no explicit reference was found in the text == Unused Reference: 'RFC7517' is defined on line 709, but no explicit reference was found in the text == Unused Reference: 'RFC7518' is defined on line 713, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-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-02 Summary: 3 errors (**), 0 flaws (~~), 6 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: January 9, 2020 Arm Ltd. 6 D. Wheeler 7 Intel 8 July 8, 2019 10 The Open Trust Protocol (OTrP) v2 11 draft-tschofenig-teep-otrp-v2-00 13 Abstract 15 This document specifies the Open Trust Protocol (OTrP) version 2, a 16 protocol that provisions and installs, updates, and deletes Trusted 17 Applications in a device with a Trusted Execution Environment (TEE). 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 9, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 55 3. OTrP Message Overview . . . . . . . . . . . . . . . . . . . . 3 56 4. Detailed Messages Specification . . . . . . . . . . . . . . . 4 57 5. Security Consideration . . . . . . . . . . . . . . . . . . . 11 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 60 7.1. Normative References . . . . . . . . . . . . . . . . . . 15 61 7.2. Informative References . . . . . . . . . . . . . . . . . 16 62 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17 63 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 17 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 66 1. Introduction 68 The Trusted Execution Environment (TEE) concept has been designed to 69 separate a regular operating system, also referred as a Rich 70 Execution Environment (REE), from security-sensitive applications. 71 In an TEE ecosystem, different device vendors may use different 72 operating systems in the REE and may use different types of TEEs. 73 When application providers or device administrators use Trusted 74 Application Managers (TAMs) to install, update, and delete Trusted 75 Applications (TAs) on a wide range of devices with potentially 76 different TEEs then an interoperability need arises. 78 This document specifies version 2 of the Open Trust Protocol (OTrP), 79 a protocol for communicating between an OTrP server (as part of a 80 TAM) and an OTrP client (which is a client-side component running in 81 the REE). 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. 87 2. Requirements Language 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 This specification re-uses the terminology defined in 94 [I-D.ietf-teep-architecture]. 96 3. OTrP Message Overview 98 OTrP consists of a couple of messages exchanged between a TAM and an 99 OTrP Agent via an OTrP Broker. The messages are encoded either in 100 JSON or CBOR and designed to provide end-to-end security. OTrP 101 messages are signed and/or encrypted by the endpoints, i.e., TAM and 102 OTrP Agent, but trusted applications may as well be encrypted and 103 signed by the service provider. OTrP not only re-uses JSON and CBOR 104 but also the respective security wrappers, namely JOSE (JWS [RFC7515] 105 and JWE [RFC7516], to be more specific) and COSE [RFC8152]. 106 Furthermore, for attestation the Entity Attestation Token (EAT) and 107 for software updates the SUIT manifest format is re-used. 109 This specification defines six messages. 111 A TAM queries a device's current state with a QueryRequest message. 112 An OTrP Agent will, after authenticating and authorizing the request, 113 report attestation information, list all TAs, and provide information 114 about supported algorithms and extensions in a QueryResponse message. 115 An error message is returned if the request could not be processed. 116 A TAM will process the QueryResponse message and determine whether 117 subsequent message exchanges to install, update, or delete trusted 118 applications shall be initiated. 120 +------------+ +-------------+ 121 | TAM | |OTrP Agent | 122 +------------+ +-------------+ 124 QueryRequest -------> 126 QueryResponse 128 <------- or 130 Error 132 With the TrustedAppInstall message a TAM can instruct an OTrP Agent 133 to install a TA. The OTrP Agent will process the message, determine 134 whether the TAM is authorized and whether the TA has been signed by 135 an authorized SP. In addition to the binary, the TAM may also 136 provide personalization data. If the TrustedAppInstall message was 137 processed successfully then a Success message is returned to the TAM, 138 an Error message otherwise. 140 +------------+ +-------------+ 141 | TAM | |OTrP Agent | 142 +------------+ +-------------+ 144 TrustedAppInstall ----> 146 Success 148 <---- or 150 Error 152 With the TrustedAppDelete message a TAM can instruct an OTrP Agent to 153 delete one or multiple TA(s). A Success message is returned when the 154 operation has been completed successfully, and an Error message 155 otherwise. 157 +------------+ +-------------+ 158 | TAM | |OTrP Agent | 159 +------------+ +-------------+ 161 TrustedAppDelete ----> 163 Success 165 <---- or 167 Error 169 4. Detailed Messages Specification 171 For a CBOR-based encoding the following security wrapper is used 172 (described in CDDL format [I-D.ietf-cbor-cddl]). 174 Outer_Wrapper = { 175 msg-authenc-wrapper => bstr .cbor 176 Msg_AuthEnc_Wrapper / nil, 177 otrp-message => (QueryRequest / 178 QueryResponse / 179 TrustedAppInstall / 180 TrustedAppDelete / 181 Error / 182 Success ), 183 } 185 msg-authenc-wrapper = 1 186 otrp-message = 2 188 Msg_AuthEnc_Wrapper = [ * (COSE_Mac_Tagged / 189 COSE_Sign_Tagged / 190 COSE_Mac0_Tagged / 191 COSE_Sign1_Tagged)] 193 A future version of this specification will also describe the 194 security wrapper for JSON (in CDDL format). 196 suite = int 198 version = int 200 data_items = ( 201 attestation: 1, 202 ta: 2, 203 ext: 3 204 ) 206 QueryRequest = ( 207 TYPE : int, 208 TOKEN : bstr, 209 REQUEST : [+data_items], 210 ? CIPHER_SUITE : [+suite], 211 ? NONCE : bstr, 212 ? VERSION : [+version], 213 ? OCSP_DATA : bstr, 214 * $$extensions 215 ) 217 A QueryRequest message is signed by the TAM and has the following 218 fields: 220 TYPE TYPE = 1 corresponds to a QueryRequest message sent from the 221 TAM to the OTrP Agent. 223 TOKEN The value in the TOKEN field is used to match requests to 224 responses. 226 REQUEST The REQUEST field indicates what information the TAM 227 requests from the OTrP Agent in form of a list of integer values. 228 Each integer value corresponds to an IANA registered information 229 element. This specification defines the initial set of 230 information elements. With 'attestation' (1) the TAM requests the 231 OTrP Agent to return an EAT entity attestation token in the 232 response, with 'ta' (2) the TAM wants to query the OTrP Agent for 233 all installed TAs, and with 'ext' (3) the TAM wants to query the 234 OTrP Agent for supported extensions. Further values may be added 235 in the future via IANA registration. 237 CIPHER_SUITE The CIPHER_SUITE field lists the ciphersuite(s) 238 supported by the TAM. 240 NONCE NONCE is an optional field used for ensuring the refreshness 241 of the Entity Attestation Token (EAT) contained in the response. 243 VERSION The VERSION field lists the version(s) supported by the TAM. 244 For this version of the specification this field can be omitted. 246 OCSP_DATA The OCSP_DATA field contains a list of OCSP stapling data 247 respectively for the TAM certificate and each of the CA 248 certificates up to the root certificate. The TAM provides OCSP 249 data so that the OTrP Agent can validate the status of the TAM 250 certificate chain without making its own external OCSP service 251 call. 253 ta_id = ( 254 Vendor_ID = bstr, 255 Class_ID = bstr, 256 Device_ID = bstr, 257 * $$extensions 258 ) 260 ext_info = int 262 QueryResponse = ( 263 TYPE : int, 264 TOKEN : bstr, 265 ? SELECTED_CIPHER_SUITE : suite, 266 ? SELECTED_VERSION : version, 267 ? EAT : bstr, 268 ? TA_LIST : [+ta_id], 269 ? EXT_LIST : [+ext_info], 270 * $$extensions 271 ) 273 The QueryResponse message is signed and encrypted by the OTrP Agent 274 and returned to the TAM. It has the following fields: 276 TYPE TYPE = 2 corresponds to a QueryResponse message sent from the 277 OTrP Agent to the TAM. 279 TOKEN The value in the TOKEN field is used to match requests to 280 responses. The value MUST correspond to the value received with 281 the QueryRequest. 283 SELECTED_CIPHER_SUITE The SELECTED_CIPHER_SUITE field indicates the 284 selected ciphersuite. 286 SELECTED_VERSION The SELECTED_VERSION field indicates the OTrP 287 protocol version selected by the OTrP Agent. 289 EAT The EAT field contains an Entity Attestation Token following the 290 encoding defined in [I-D.ietf-rats-eat]. 292 TA_LIST The TA_LIST field enumerates the trusted applications 293 installed on the device in form of ta_ids, i.e., a vendor id/class 294 id/device id triple. 296 EXT_LIST The EXT_LIST field lists the supported extensions. This 297 document does not define any extensions. 299 TrustedAppInstall = ( 300 TYPE : int, 301 TOKEN : bstr, 302 ? TA : [+SUIT_Outer_Wrapper], 303 * $$extensions 304 ) 306 The TrustedAppInstall message is MACed and encrypted by the TAM and 307 has the following fields: 309 TYPE TYPE = 3 corresponds to a TrustedAppInstall message sent from 310 the TAM to the OTrP Agent. In case of successful processing, an 311 Success message is returned by the OTrP Agent. In case of an 312 error, an Error message is returned. Note that the 313 TrustedAppInstall message is used for initial TA installation but 314 also for TA updates. 316 TOKEN The value in the TOKEN field is used to match requests to 317 responses. 319 TA The TA field is used to convey one or multiple SUIT manifests. 320 The SUIT manifest contains the code for the trusted app but may 321 also convey personalization data. TA binaries and personalization 322 data is often signed and encrypted by the SP. Other combinations 323 are, however, possible as well. For example, it is also possible 324 for the TAM to sign and encrypt the personalization data and to 325 let the SP sign and/or encrypt the TA binary. 327 TrustedAppDelete = ( 328 TYPE : int, 329 TOKEN : bstr, 330 ? TA_LIST : [+ta_id], 331 * $$extensions 332 ) 334 The TrustedAppDelete message is MACed and encrypted by the TAM and 335 has the following fields: 337 TYPE TYPE = 4 corresponds to a TrustedAppDelete message sent from 338 the TAM to the OTrP Agent. In case of successful processing, an 339 Success message is returned by the OTrP Agent. In case of an 340 error, an Error message is returned. 342 TOKEN The value in the TOKEN field is used to match requests to 343 responses. 345 TA_LIST The TA_LIST field enumerates the TAs to be deleted. 347 Success = ( 348 TYPE : int, 349 TOKEN : bstr, 350 ? MSG : tstr, 351 * $$extensions 352 ) 354 The Success message is MACed and encrypted by the OTrP Agent and has 355 the following fields: 357 TYPE TYPE = 5 corresponds to a Error message sent from the OTrP 358 Agent to the TAM. 360 TOKEN The value in the TOKEN field is used to match requests to 361 responses. 363 MSG The MSG field contains optional diagnostics information encoded 364 in UTF-8 [RFC3629] returned by the OTrP Agent. 366 Error = ( 367 TYPE : int, 368 TOKEN : bstr, 369 ERR_CODE : int, 370 ? ERR_MSG : tstr, 371 ? CIPHER_SUITE : [+suite], 372 ? VERSION : [+version], 373 * $$extensions 374 ) 376 If possible, the Error message is MACed and encrypted by the OTrP 377 Agent. Unprotected Error messages MUST be handled with care by the 378 TAM due to possible downgrading attacks. It has the following 379 fields: 381 TYPE TYPE = 6 corresponds to a Error message sent from the OTrP 382 Agent to the TAM. 384 TOKEN The value in the TOKEN field is used to match requests to 385 responses. 387 ERR_CODE The ERR_CODE field is populated with values listed in a 388 registry (with the initial set of error codes listed below). Only 389 selected messages are applicable to each message. 391 ERR_MSG The ERR_MSG message is a human-readable diagnostic message 392 that MUST be encoded using UTF-8 [RFC3629] using Net-Unicode form 393 [RFC5198]. 395 VERSION The VERSION field enumerates the protocol version(s) 396 supported by the OTrP Agent. This field is optional but MUST be 397 returned with the ERR_UNSUPPORTED_MSG_VERSION error message. 399 CIPHER_SUITE The CIPHER_SUITE field lists the ciphersuite(s) 400 supported by the OTrP Agent. This field is optional but MUST be 401 returned with the ERR_UNSUPPORTED_CRYPTO_ALG error message. 403 This specification defines the following initial error messages. 404 Additional error code can be registered with IANA. 406 ERR_ILLEGAL_PARAMETER The OTrP Agent sends this error message when a 407 request contains incorrect fields or fields that are inconsistent 408 with other fields. 410 ERR_UNSUPPORTED_EXTENSION The OTrP Agent sends this error message 411 when it recognizes an unsupported extension or unsupported 412 message. 414 ERR_REQUEST_SIGNATURE_FAILED The OTrP Agent sends this error message 415 when it fails to verify the signature of the message. 417 ERR_UNSUPPORTED_MSG_VERSION The OTrP Agent receives a message but 418 does not support the indicated version. 420 ERR_UNSUPPORTED_CRYPTO_ALG The OTrP Agent receives a request message 421 encoded with an unsupported cryptographic algorithm. 423 ERR_BAD_CERTIFICATE The OTrP Agent returns this error when 424 processing of a certificate failed. For diagnosis purposes it is 425 RECOMMMENDED to include information about the failing certificate 426 in the error message. 428 ERR_UNSUPPORTED_CERTIFICATE The OTrP Agent returns this error when a 429 certificate was of an unsupported type. 431 ERR_CERTIFICATE_REVOKED The OTrP Agent returns this error when a 432 certificate was revoked by its signer. 434 ERR_CERTIFICATE_EXPIRED The OTrP Agent returns this error when a 435 certificate has expired or is not currently valid. 437 ERR_INTERNAL_ERROR The OTrP Agent returns this error when a 438 miscellaneous internal error occurred while processing the 439 request. 441 ERR_RESOURCE_FULL This error is reported when a device resource 442 isn't available anymore, such as storage space is full. 444 ERR_TA_NOT_FOUND This error will occur when the target TA does not 445 exist. This error may happen when the TAM has stale information 446 and tries to delete a TA that has already been deleted. 448 ERR_TA_ALREADY_INSTALLED While installing a TA, a TEE will return 449 this error if the TA has already been installed. 451 ERR_TA_UNKNOWN_FORMAT The OTrP Agent returns this error when it does 452 not recognize the format of the TA binary. 454 ERR_TA_DECRYPTION_FAILED The OTrP Agent returns this error when it 455 fails to decrypt the TA binary. 457 ERR_TA_DECOMPRESSION_FAILED The OTrP Agent returns this error when 458 it fails to decompress the TA binary. 460 ERR_MANIFEST_PROCESSING_FAILED The OTrP Agent returns this error 461 when manifest processing failures occur that are less specific 462 than ERR_TA_UNKNOWN_FORMAT, ERR_TA_UNKNOWN_FORMAT, and 463 ERR_TA_DECOMPRESSION_FAILED. 465 ERR_PD_PROCESSING_FAILED The OTrP Agent returns this error when it 466 fails to process the provided personalization data. 468 5. Security Consideration 470 This section summarizes the security considerations discussed in this 471 specification: 473 Cryptographic Algorithms This specification relies on the 474 cryptographic algorithms provided by the security wrappers JOSE 475 and COSE, respectively. A companion document makes algorithm 476 recommendations but this document is written in an algorithm- 477 agnostic way. OTrP messages between the TAM and the OTrP Agent 478 are protected using JWS and JWE (for JSON-encoded messages) and 479 COSE (for CBOR-encoded messages). Public key based authentication 480 is used to by the OTrP Agent to authenticate the TAM and vice 481 versa. 483 Attestation A TAM may rely on the attestation information provided 484 by the OTrP Agent and the Entity Attestation Token is re-used to 485 convey this information. To sign the Entity Attestation Token it 486 is necessary for the device to possess a public key (usually in 487 the form of a certificate) along with the corresponding private 488 key. Depending on the properties of the attestation mechanism it 489 is possible to uniquely identify a device based on information in 490 the attestation information or in the certificate used to sign the 491 attestation token. This uniqueness may raise privacy concerns. 493 To lower the privacy implications the OTrP Agent MUST present its 494 attestation information only to an authenticated and authorized 495 TAM. 497 TA Binaries TA binaries are provided by the SP.It is the 498 responsibility of the TAM to relay only verified TAs from 499 authorized SPs. Delivery of that TA to the OTrP Agent is then the 500 responsibility of the TAM and the OTrP Broker, using the security 501 mechanisms provided by the OTrP. To protect the TA binary the 502 SUIT manifest is re-used and it offers a varity of security 503 features, including digitial signatures and symmetric encryption. 505 Personalization Data An SP or a TAM can supply personalization data 506 along with a TA. This data is also protected by a SUIT manifest. 507 The personalization data may be itself is (or can be) opaque to 508 the TAM. 510 OTrP Broker OTrP relies on the OTrP Broker to relay messages between 511 the TAM and the OTrP Agent. When the OTrP Broker is compromised 512 it can drop, relay, and replay messages but it cannot modify those 513 messages. A compromised OTrP Broker could reorder TAM messages to 514 install an old version of a TA. Information in the manifest 515 ensures that the OTrP Agents are protected against such 516 downgrading attacks. 518 CA Compromise The QueryRequest message from a TAM to the OTrP Agent 519 may include OCSP stapling data for the TAM's signer certificate 520 and for intermediate CA certificates up to the root certificate so 521 that the OTrP Agent can verify the certificate's revocation 522 status. 524 A certificate revocation status check on a TA signer certificate 525 is OPTIONAL by an OTrP Agent. A TAM is responsible for vetting a 526 TA and before distributing them to OTrP Agents. The OTrP Agents 527 will trust a TA signer certificate's validation status done by a 528 TAM. 530 CA Compromise The CA issuing certificates to a TAM or an SP may get 531 compromised. A compromised intermediate CA certificates can be 532 detected by an OTrP Agent by using OCSP information, assuming the 533 revocation information is available. Additionally, it is 534 RECOMMENDED to provide a way to update the trust anchor store used 535 by the device, for example using a firmware update mechanism. 537 If the CA issuing certificates to devices gets compromised then 538 these devices might be rejected by a TAM, if revocation is 539 available to the TAM. 541 Compromised TAM The OTrP Agent SHOULD use OCSP information to verify 542 the validity of the TAM-provided certificate (as well as the 543 validity of intermediate CA certificates). The integrity and the 544 accuracy of the clock within the TEE determines the ability to 545 determine an expired or revoked certificate since OCSP stapling 546 includes signature generation time, certificate validity dates are 547 compared to the current time. 549 6. IANA Considerations 551 There are two IANA requests: a media type and list of error codes. 553 IANA is requested to assign a media type for application/otrpv2+json. 555 Type name: application 557 Subtype name: otrp+json 559 Required parameters: none 561 Optional parameters: none 563 Encoding considerations: Same as encoding considerations of 564 application/json as specified in Section 11 of [RFC7159] 566 Security considerations: See Security Considerations Section of this 567 document. 569 Interoperability considerations: Same as interoperability 570 considerations of application/json as specified in [RFC7159] 572 Published specification: This document. 574 Applications that use this media type: OTrPv2 implementations 576 Fragment identifier considerations: N/A 578 Additional information: 580 Deprecated alias names for this type: N/A 582 Magic number(s): N/A 584 File extension(s): N/A 586 Macintosh file type code(s): N/A 588 Person to contact for further information: teep@ietf.org 589 Intended usage: COMMON 591 Restrictions on usage: none 593 Author: See the "Authors' Addresses" section of this document 595 Change controller: IETF 597 IANA is requested to assign a media type for application/otrpv2+cbor. 599 Type name: application 601 Subtype name: otrpv2+cbor 603 Required parameters: none 605 Optional parameters: none 607 Encoding considerations: Same as encoding considerations of 608 application/cbor 610 Security considerations: See Security Considerations Section of this 611 document. 613 Interoperability considerations: Same as interoperability 614 considerations of application/cbor as specified in [RFC7049] 616 Published specification: This document. 618 Applications that use this media type: OTrPv2 implementations 620 Fragment identifier considerations: N/A 622 Additional information: 624 Deprecated alias names for this type: N/A 626 Magic number(s): N/A 628 File extension(s): N/A 630 Macintosh file type code(s): N/A 632 Person to contact for further information: teep@ietf.org 634 Intended usage: COMMON 636 Restrictions on usage: none 637 Author: See the "Authors' Addresses" section of this document 639 Change controller: IETF 641 IANA is also requested to create a new registry for the error codes 642 defined in Section 4. 644 Registration requests are evaluated after a three-week review period 645 on the otrp-reg-review@ietf.org mailing list, on the advice of one or 646 more Designated Experts [RFC8126]. However, to allow for the 647 allocation of values prior to publication, the Designated Experts may 648 approve registration once they are satisfied that such a 649 specification will be published. 651 Registration requests sent to the mailing list for review should use 652 an appropriate subject (e.g., "Request to register an error code: 653 example"). Registration requests that are undetermined for a period 654 longer than 21 days can be brought to the IESG's attention (using the 655 iesg@ietf.org mailing list) for resolution. 657 Criteria that should be applied by the Designated Experts includes 658 determining whether the proposed registration duplicates existing 659 functionality, whether it is likely to be of general applicability or 660 whether it is useful only for a single extension, and whether the 661 registration description is clear. 663 IANA must only accept registry updates from the Designated Experts 664 and should direct all requests for registration to the review mailing 665 list. 667 7. References 669 7.1. Normative References 671 [I-D.ietf-rats-eat] 672 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 673 O'Donoghue, "The Entity Attestation Token (EAT)", draft- 674 ietf-rats-eat-01 (work in progress), July 2019. 676 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 677 Requirement Levels", BCP 14, RFC 2119, 678 DOI 10.17487/RFC2119, March 1997, 679 . 681 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 682 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 683 2003, . 685 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 686 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 687 . 689 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 690 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 691 . 693 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 694 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 695 October 2013, . 697 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 698 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 699 2014, . 701 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 702 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 703 2015, . 705 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 706 RFC 7516, DOI 10.17487/RFC7516, May 2015, 707 . 709 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 710 DOI 10.17487/RFC7517, May 2015, 711 . 713 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 714 DOI 10.17487/RFC7518, May 2015, 715 . 717 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 718 RFC 8152, DOI 10.17487/RFC8152, July 2017, 719 . 721 7.2. Informative References 723 [I-D.ietf-cbor-cddl] 724 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 725 definition language (CDDL): a notational convention to 726 express CBOR and JSON data structures", draft-ietf-cbor- 727 cddl-08 (work in progress), March 2019. 729 [I-D.ietf-teep-architecture] 730 Pei, M., Tschofenig, H., Wheeler, D., Atyeo, A., and D. 731 Liu, "Trusted Execution Environment Provisioning (TEEP) 732 Architecture", draft-ietf-teep-architecture-02 (work in 733 progress), March 2019. 735 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 736 Writing an IANA Considerations Section in RFCs", BCP 26, 737 RFC 8126, DOI 10.17487/RFC8126, June 2017, 738 . 740 Appendix A. Acknowledgements 742 This work is based on the initial version of OTrP and hence credits 743 go to those who have contributed to it. 745 Appendix B. Contributors 747 We would like to thank the following individuals for their 748 contributions to an earlier version of this specification. 750 - Brian Witten 751 Symantec 752 brian_witten@symantec.com 754 - Tyler Kim 755 Solacia 756 tylerkim@iotrust.kr 758 - Nick Cook 759 Arm Ltd. 760 nicholas.cook@arm.com 762 - Minho Yoo 763 IoTrust 764 minho.yoo@iotrust.kr 766 Authors' Addresses 768 Mingliang Pei 769 Symantec 770 350 Ellis St 771 Mountain View, CA 94043 772 USA 774 Email: mingliang_pei@symantec.com 775 Hannes Tschofenig 776 Arm Ltd. 777 110 Fulbourn Rd 778 Cambridge, CB1 9NJ 779 Great Britain 781 Email: hannes.tschofenig@arm.com 783 David Wheeler 784 Intel 785 US 787 Email: david.m.wheeler@intel.com