idnits 2.17.1 draft-ietf-teep-otrp-over-http-02.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 (October 22, 2019) is 1648 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-semantics-05 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) == Outdated reference: A later version (-15) exists of draft-ietf-httpbis-bcp56bis-08 == Outdated reference: A later version (-19) exists of draft-ietf-teep-architecture-03 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEEP WG D. Thaler 3 Internet-Draft Microsoft 4 Intended status: Informational October 22, 2019 5 Expires: April 24, 2020 7 HTTP Transport for Trusted Execution Environment Provisioning: Agent-to- 8 TAM Communication 9 draft-ietf-teep-otrp-over-http-02 11 Abstract 13 The Open Trust Protocol (OTrP) is used to manage code and 14 configuration data in a Trusted Execution Environment (TEE). This 15 document specifies the HTTP transport for OTrP communication where a 16 Trusted Application Manager (TAM) service is used to manage TEEs in 17 devices that can initiate communication to the TAM. An 18 implementation of this document can (if desired) run outside of any 19 TEE, but interacts with an OTrP implementation that runs inside a 20 TEE. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 24, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. TEEP Broker Models . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Use of Abstract APIs . . . . . . . . . . . . . . . . . . 5 60 4. Use of HTTP as a Transport . . . . . . . . . . . . . . . . . 6 61 5. OTrP/HTTP Client Behavior . . . . . . . . . . . . . . . . . . 7 62 5.1. Receiving a request to install a new Trusted Application 7 63 5.1.1. Session Creation . . . . . . . . . . . . . . . . . . 7 64 5.2. Getting a message buffer back from an OTrP implementation 8 65 5.3. Receiving an HTTP response . . . . . . . . . . . . . . . 8 66 5.4. Handling checks for policy changes . . . . . . . . . . . 9 67 5.5. Error handling . . . . . . . . . . . . . . . . . . . . . 9 68 6. OTrP/HTTP Server Behavior . . . . . . . . . . . . . . . . . . 10 69 6.1. Receiving an HTTP POST request . . . . . . . . . . . . . 10 70 6.2. Getting an empty buffer back from the OTrP implementation 10 71 6.3. Getting a message buffer from the OTrP implementation . . 10 72 6.4. Error handling . . . . . . . . . . . . . . . . . . . . . 10 73 7. Sample message flow . . . . . . . . . . . . . . . . . . . . . 10 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 78 10.2. Informative References . . . . . . . . . . . . . . . . . 13 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 Trusted Execution Environments (TEEs), including environments based 84 on Intel SGX, ARM TrustZone, Secure Elements, and others, enforce 85 that only authorized code can execute within the TEE, and any memory 86 used by such code is protected against tampering or disclosure 87 outside the TEE. The Open Trust Protocol (OTrP) is designed to 88 provision authorized code and configuration into TEEs. 90 To be secure against malware, an OTrP implementation (referred to as 91 a TEEP "Agent" on the client side, and a "Trusted Application Manager 92 (TAM)" on the server side) must themselves run inside a TEE. 93 However, the transport for OTrP, along with the underlying TCP/IP 94 stack, does not necessarily run inside a TEE. This split allows the 95 set of highly trusted code to be kept as small as possible, including 96 allowing code (e.g., TCP/IP) that only sees encrypted messages to be 97 kept out of the TEE. 99 The OTrP specification ([I-D.ietf-teep-opentrustprotocol] or 100 [I-D.tschofenig-teep-otrp-v2]) describes the behavior of TEEP Agents 101 and TAMs, but does not specify the details of the transport. The 102 purpose of this document is to provide such details. That is, an 103 OTrP over HTTP (OTrP/HTTP) implementation delivers messages up to an 104 OTrP implementation, and accepts messages from the OTrP 105 implementation to be sent over a network. The OTrP over HTTP 106 implementation can be implemented either outside a TEE (i.e., in a 107 TEEP "Broker") or inside a TEE. 109 There are two topological scenarios in which OTrP could be deployed: 111 1. TAMs are reachable on the Internet, and Agents are on networks 112 that might be behind a firewall, so that communication must be 113 initiated by an Agent. Thus, the Agent has an HTTP Client and 114 the TAM has an HTTP Server. 116 2. Agents are reachable on the Internet, and TAMs are on networks 117 that might be behind a firewall, so that communication must be 118 initiated by a TAM. Thus, the Agent has an HTTP Server and the 119 TAM has an HTTP Client. 121 The remainder of this document focuses primarily on the first 122 scenario as depicted in Figure 1, but some sections (Section 4 and 123 Section 8) may apply to the second scenario as well. A fuller 124 discussion of the second scenario may be handled by a separate 125 document. 127 +------------------+ OTrP +------------------+ 128 | TEEP Agent | <----------------------> | TAM | 129 +------------------+ +------------------+ 130 | | 131 +------------------+ OTrP over HTTP +------------------+ 132 | OTrP/HTTP Client | <----------------------> | OTrP/HTTP Server | 133 +------------------+ +------------------+ 134 | | 135 +------------------+ HTTP +------------------+ 136 | HTTP Client | <----------------------> | HTTP Server | 137 +------------------+ +------------------+ 139 Figure 1: Agent-to-TAM Communication 141 2. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in BCP 146 14 [RFC2119] [RFC8174] when, and only when, they appear in all 147 capitals, as shown here. 149 This document also uses various terms defined in 150 [I-D.ietf-teep-architecture], including Trusted Execution Environment 151 (TEE), Trusted Application (TA), Trusted Application Manager (TAM), 152 TEEP Agent, TEEP Broker, and Rich Execution Environment (REE). 154 3. TEEP Broker Models 156 Section 6 of the TEEP architecture [I-D.ietf-teep-architecture] 157 defines a TEEP "Broker" as being a component on the device, but 158 outside the TEE, that facilitates communication with a TAM. As 159 depicted in Figure 2, there are multiple ways in which this can be 160 implemented, with more or fewer layers being inside the TEE. For 161 example, in model A, the model with the smallest TEE footprint, only 162 the OTrP implementation is inside the TEE, whereas the OTrP/HTTP 163 implementation is in the TEEP Broker outside the TEE. 165 Model: A B C ... 167 TEE TEE TEE 168 +----------------+ | | | 169 | OTrP | Agent | | | Agent 170 | implementation | | | | 171 +----------------+ v | | 172 | | | 173 +----------------+ ^ | | 174 | OTrP/HTTP | Broker | | | 175 | implementation | | | | 176 +----------------+ | v | 177 | | | 178 +----------------+ | ^ | 179 | HTTP | | | | 180 | implementation | | | | 181 +----------------+ | | v 182 | | | 183 +----------------+ | | ^ 184 | TCP or QUIC | | | | Broker 185 | implementation | | | | 186 +----------------+ | | | 187 REE REE REE 189 Figure 2: TEEP Broker Models 191 In other models, additional layers are moved into the TEE, increasing 192 the TEE footprint, with the Broker either containing or calling the 193 topmost protocol layer outside of the TEE. An implementation is free 194 to choose any of these models, although model A is the one we will 195 use in our examples. 197 Passing information from an REE component to a TEE component is 198 typically spoken of as being passed "in" to the TEE, and informaton 199 passed in the opposite direction is spoken of as being passed "out". 200 In the protocol layering sense, information is typically spoken of as 201 being passed "up" or "down" the stack. Since the layer at which 202 information is passed in/out may vary by implementation, we will 203 generally use "up" and "down" in this document. 205 3.1. Use of Abstract APIs 207 This document refers to various APIs between an OTrP implementation 208 and an OTrP/HTTP implementation in the abstract, meaning the literal 209 syntax and programming language are not specified, so that various 210 concrete APIs can be designed (outside of the IETF) that are 211 compliant. 213 Some TEE architectures (e.g., SGX) may support API calls both into 214 and out of a TEE. In other TEE architectures, there may be no calls 215 out from a TEE, but merely data returned from calls into a TEE. This 216 document attempts to be agnostic as to the concrete API architecture 217 for Broker/Agent communication. Since in model A, the Broker/Agent 218 communication is done at the layer between the OTrP and OTrP/HTTP 219 implementations, and there may be some architectures that do not 220 support calls out of the TEE (which would be downcalls from OTrP in 221 model A), we will refer to passing information up to the OTrP 222 implementation as API calls, but will simply refer to "passing data" 223 back down from an OTrP implementation. A concrete API might pass 224 data back via an API downcall or via data returned from an API 225 upcall. 227 This document will also refer to passing "no" data back out of an 228 OTrP implementation. In a concrete API, this might be implemented by 229 not making any downcall, or by returning 0 bytes from an upcall, for 230 example. 232 4. Use of HTTP as a Transport 234 This document uses HTTP [I-D.ietf-httpbis-semantics] as a transport. 235 When not called out explicitly in this document, all implementation 236 recommendations in [I-D.ietf-httpbis-bcp56bis] apply to use of HTTP 237 by OTrP. 239 Redirects MAY be automatically followed, and no additional request 240 headers beyond those specified by HTTP need be modified or removed 241 upon a following such a redirect. 243 Content is not intended to be treated as active by browsers and so 244 HTTP responses with content SHOULD have the following headers as 245 explained in Section 4.12 of [I-D.ietf-httpbis-bcp56bis] (replacing 246 the content type with the relevant OTrP content type per the OTrP 247 specification): 249 Content-Type: 250 Cache-Control: no-store 251 X-Content-Type-Options: nosniff 252 Content-Security-Policy: default-src 'none' 253 Referrer-Policy: no-referrer 255 Only the POST method is specified for TAM resources exposed over 256 HTTP. A URI of such a resource is referred to as a "TAM URI". A TAM 257 URI can be any HTTP(S) URI. The URI to use is configured in a TEEP 258 Agent via an out-of-band mechanism, as discussed in the next section. 260 When HTTPS is used, TLS certificates MUST be checked according to 261 [RFC2818]. 263 5. OTrP/HTTP Client Behavior 265 5.1. Receiving a request to install a new Trusted Application 267 In some environments, an application installer can determine (e.g., 268 from an app manifest) that the application being installed or updated 269 has a dependency on a given Trusted Application (TA) being available 270 in a given type of TEE. In such a case, it will notify a TEEP 271 Broker, where the notification will contain the following: 273 - A unique identifier of the TA 275 - Optionally, any metadata to provide to the OTrP implementation. 276 This might include a TAM URI provided in the application manifest, 277 for example. 279 - Optionally, any requirements that may affect the choice of TEE, if 280 multiple are available to the TEEP Broker. 282 When a TEEP Broker receives such a notification, it first identifies 283 in an implementation-dependent way which TEE (if any) is most 284 appropriate based on the constraints expressed. If there is only one 285 TEE, the choice is obvious. Otherwise, the choice might be based on 286 factors such as capabilities of available TEE(s) compared with TEE 287 requirements in the notification. Once the TEEP Broker picks a TEE, 288 it passes the notification to the OTrP/HTTP Cient for that TEE. 290 The OTrP/HTTP Client then informs the OTrP implementation in that TEE 291 by invoking an appropriate "RequestTA" API that identifies the TA 292 needed and any other associated metadata. The OTrP/HTTP Client need 293 not know whether the TEE already has such a TA installed or whether 294 it is up to date. 296 The OTrP implementation will either (a) pass no data back, (b) pass 297 back a TAM URI to connect to, or (c) pass back a message buffer and 298 TAM URI to send it to. The TAM URI passed back may or may not be the 299 same as the TAM URI, if any, provided by the OTrP/HTTP Client, 300 depending on the OTrP implementation's configuration. If they 301 differ, the OTrP/HTTP Client MUST use the TAM URI passed back. 303 5.1.1. Session Creation 305 If no data is passed back, the OTrP/HTTP Client simply informs its 306 caller (e.g., the application installer) of success. 308 If the OTrP implementation passes back a TAM URI with no message 309 buffer, the OTrP/HTTP Client attempts to create session state, then 310 sends an HTTP(S) POST to the TAM URI with an Accept header and an 311 empty body. The HTTP request is then associated with the OTrP/HTTP 312 Client's session state. 314 If the OTrP implementation instead passes back a TAM URI with a 315 message buffer, the OTrP/HTTP Client attempts to create session state 316 and handles the message buffer as specified in Section 5.2. 318 Session state consists of: 320 - Any context (e.g., a handle) that identifies the API session with 321 the OTrP implementation. 323 - Any context that identifies an HTTP request, if one is 324 outstanding. Initially, none exists. 326 5.2. Getting a message buffer back from an OTrP implementation 328 When an OTrP implementation passes a message buffer (and TAM URI) to 329 an OTrP/HTTP Client, the OTrP/HTTP Client MUST do the following, 330 using the OTrP/HTTP Client's session state associated with its API 331 call to the OTrP implementation. 333 The OTrP/HTTP Client sends an HTTP POST request to the TAM URI with 334 Accept and Content-Type headers with the OTrP media type in use, and 335 a body containing the OTrP message buffer provided by the OTrP 336 implementation. The HTTP request is then associated with the OTrP/ 337 HTTP Client's session state. 339 5.3. Receiving an HTTP response 341 When an HTTP response is received in response to a request associated 342 with a given session state, the OTrP/HTTP Client MUST do the 343 following. 345 If the HTTP response body is empty, the OTrP/HTTP Client's task is 346 complete, and it can delete its session state, and its task is done. 348 If instead the HTTP response body is not empty, the OTrP/HTTP Client 349 calls a "ProcessOTrPMessage" API (Section 6.2 of 350 [I-D.ietf-teep-opentrustprotocol]) to pass the response body up to 351 the OTrP implementation associated with the session. The OTrP 352 implementation will then either pass no data back, or pass back a 353 message buffer. 355 If no data is passed back, the OTrP/HTTP Client's task is complete, 356 and it can delete its session state, and inform its caller (e.g., the 357 application installer) of success. 359 If instead the OTrP implementation passes back a message buffer, the 360 OTrP/HTTP Client handles the message buffer as specified in 361 Section 5.2. 363 5.4. Handling checks for policy changes 365 An implementation MUST provide a way to periodically check for OTrP 366 policy changes. This can be done in any implementation-specific 367 manner, such as: 369 A) The OTrP/HTTP Client might call up to the OTrP implementation at 370 an interval previously specified by the OTrP implementation. This 371 approach requires that the OTrP/HTTP Client be capable of running a 372 periodic timer. 374 B) The OTrP/HTTP Client might be informed when an existing TA is 375 invoked, and call up to the OTrP implementation if more time has 376 passed than was previously specified by the OTrP implementation. 377 This approach allows the device to go to sleep for a potentially long 378 period of time. 380 C) The OTrP/HTTP Client might be informed when any attestation 381 attempt determines that the device is out of compliance, and call up 382 to the OTrP implementation to remediate. 384 The OTrP/HTTP Client informs the OTrP implementation by invoking an 385 appropriate "RequestPolicyCheck" API. The OTrP implementation will 386 either (a) pass no data back, (b) pass back a TAM URI to connect to, 387 or (c) pass back a message buffer and TAM URI to send it to. 388 Processing then continues as specified in Section 5.1.1. 390 5.5. Error handling 392 If any local error occurs where the OTrP/HTTP Client cannot get a 393 message buffer (empty or not) back from the OTrP implementation, the 394 OTrP/HTTP Client deletes its session state, and informs its caller 395 (e.g., the application installer) of a failure. 397 If any HTTP request results in an HTTP error response or a lower 398 layer error (e.g., network unreachable), the OTrP/HTTP Client calls 399 the OTrP implementation's "ProcessError" API, and then deletes its 400 session state and informs its caller of a failure. 402 6. OTrP/HTTP Server Behavior 404 6.1. Receiving an HTTP POST request 406 When an HTTP POST request is received with an empty body, the OTrP/ 407 HTTP Server invokes the TAM's "ProcessConnect" API. The TAM will 408 then pass back a (possibly empty) message buffer. 410 When an HTTP POST request is received with a non-empty body, the 411 OTrP/HTTP Server calls the TAM's "ProcessOTrPMessage" API to pass it 412 the request body. The TAM will then pass back a (possibly empty) 413 message buffer. 415 6.2. Getting an empty buffer back from the OTrP implementation 417 If the OTrP implementation passes back an empty buffer, the OTrP/HTTP 418 Server sends a successful (2xx) response with no body. 420 6.3. Getting a message buffer from the OTrP implementation 422 If the OTrP implementation passes back a non-empty buffer, the OTrP/ 423 HTTP Server generates a successful (2xx) response with a Content-Type 424 header with the OTrP media type in use, and with the message buffer 425 as the body. 427 6.4. Error handling 429 If any error occurs where the OTrP/HTTP Server cannot get a message 430 buffer (empty or not) back from the OTrP implementation, the OTrP/ 431 HTTP Server generates an appropriate HTTP error response. 433 7. Sample message flow 435 The following shows a sample OTrP message flow that uses application/ 436 otrp+json as the Content-Type. 438 1. An application installer determines (e.g., from an app manifest) 439 that the application has a dependency on TA "X", and passes this 440 notification to the TEEP Broker. The TEEP Broker picks a TEE 441 (e.g., the only one available) based on this notification, and 442 passes the information to the OTrP/HTTP Cient for that TEE. 444 2. The OTrP/HTTP Client calls the OTrP implementation's "RequestTA" 445 API, passing TA Needed = X. 447 3. The OTrP implementation finds that no such TA is already 448 installed, but that it can be obtained from a given TAM. The 449 TEEP Agent passes the TAM URI (e.g., "https://example.com/tam") 450 to the OTrP/HTTP Client. (If the OTrP implementation already 451 had a cached TAM certificate that it trusts, it could skip to 452 step 9 instead and generate a GetDeviceStateResponse.) 454 4. The OTrP/HTTP Client sends an HTTP POST request to the TAM URI: 456 POST /tam HTTP/1.1 457 Host: example.com 458 Accept: application/otrp+json 459 Content-Length: 0 460 User-Agent: Foo/1.0 462 5. On the TAM side, the OTrP/HTTP Server receives the HTTP POST 463 request, and calls the OTrP implementation's "ProcessConnect" 464 API. 466 6. The OTrP implementation generates an OTrP message (where 467 typically GetDeviceStateRequest is the first message) and passes 468 it to the OTrP/HTTP Server. 470 7. The OTrP/HTTP Server sends an HTTP successful response with the 471 OTrP message in the body: 473 HTTP/1.1 200 OK 474 Content-Type: application/otrp+json 475 Content-Length: [length of OTrP message here] 476 Server: Bar/2.2 477 Cache-Control: no-store 478 X-Content-Type-Options: nosniff 479 Content-Security-Policy: default-src 'none' 480 Referrer-Policy: no-referrer 482 [OTrP message here] 484 8. Back on the TEEP Agent side, the OTrP/HTTP Client gets the HTTP 485 response, extracts the OTrP message and calls the OTrP 486 implementation's "ProcessOTrPMessage" API to pass it the 487 message. 489 9. The OTrP implementation processes the OTrP message, and 490 generates an OTrP response (e.g., GetDeviceStateResponse) which 491 it passes back to the OTrP/HTTP Client. 493 10. The OTrP/HTTP Client gets the OTrP message buffer and sends an 494 HTTP POST request to the TAM URI, with the OTrP message in the 495 body: 497 POST /tam HTTP/1.1 498 Host: example.com 499 Accept: application/otrp+json 500 Content-Type: application/otrp+json 501 Content-Length: [length of OTrP message here] 502 User-Agent: Foo/1.0 504 [OTrP message here] 506 11. The OTrP/HTTP Server receives the HTTP POST request, and calls 507 the OTrP implementation's "ProcessOTrPMessage" API. 509 12. Steps 6-11 are then repeated until the OTrP implementation 510 passes no data back to the OTrP/HTTP Server in step 6. 512 13. The OTrP/HTTP Server sends an HTTP successful response with no 513 body: 515 HTTP/1.1 204 No Content 516 Server: Bar/2.2 518 14. The OTrP/HTTP Client deletes its session state. 520 8. Security Considerations 522 Although OTrP is protected end-to-end inside of HTTP, there is still 523 value in using HTTPS for transport, since HTTPS can provide 524 additional protections as discussed in Section 6 of 525 [I-D.ietf-httpbis-bcp56bis]. As such, OTrP/HTTP implementations MUST 526 support HTTPS. The choice of HTTP vs HTTPS at runtime is up to 527 policy, where an administrator configures the TAM URI to be used, but 528 it is expected that real deployments will always use HTTPS TAM URIs. 530 9. IANA Considerations 532 This document has no actions for IANA. 534 10. References 536 10.1. Normative References 538 [I-D.ietf-httpbis-semantics] 539 Fielding, R., Nottingham, M., and J. Reschke, "HTTP 540 Semantics", draft-ietf-httpbis-semantics-05 (work in 541 progress), July 2019. 543 [I-D.ietf-teep-opentrustprotocol] 544 Pei, M., Atyeo, A., Cook, N., Yoo, M., and H. Tschofenig, 545 "The Open Trust Protocol (OTrP)", draft-ietf-teep- 546 opentrustprotocol-03 (work in progress), May 2019. 548 [I-D.tschofenig-teep-otrp-v2] 549 Pei, M., Tschofenig, H., and D. Wheeler, "The Open Trust 550 Protocol (OTrP) v2", draft-tschofenig-teep-otrp-v2-00 551 (work in progress), July 2019. 553 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 554 Requirement Levels", BCP 14, RFC 2119, 555 DOI 10.17487/RFC2119, March 1997, . 558 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 559 DOI 10.17487/RFC2818, May 2000, . 562 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 563 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 564 May 2017, . 566 10.2. Informative References 568 [I-D.ietf-httpbis-bcp56bis] 569 Nottingham, M., "Building Protocols with HTTP", draft- 570 ietf-httpbis-bcp56bis-08 (work in progress), November 571 2018. 573 [I-D.ietf-teep-architecture] 574 Pei, M., Tschofenig, H., Wheeler, D., Atyeo, A., and D. 575 Liu, "Trusted Execution Environment Provisioning (TEEP) 576 Architecture", draft-ietf-teep-architecture-03 (work in 577 progress), July 2019. 579 Author's Address 581 Dave Thaler 582 Microsoft 584 EMail: dthaler@microsoft.com