idnits 2.17.1 draft-bishop-httpbis-http2-additional-certs-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([RFC7540], [I-D.ietf-tls-tls13]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 17, 2016) is 2900 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: 'I-D.josefsson-eddsa-ed25519' is defined on line 1205, but no explicit reference was found in the text == Unused Reference: 'I-D.nottingham-httpbis-origin-frame' is defined on line 1209, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-12 ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' -- Obsolete informational reference (is this intentional?): RFC 2560 (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP M. Bishop 3 Internet-Draft Microsoft 4 Intended status: Standards Track M. Thomson 5 Expires: November 18, 2016 Mozilla 6 May 17, 2016 8 Secondary Certificate Authentication in HTTP/2 9 draft-bishop-httpbis-http2-additional-certs-01 11 Abstract 13 TLS provides fundamental mutual authentication services for HTTP, 14 supporting up to one server certificate and up to one client 15 certificate associated to the session to prove client and server 16 identities as necessary. This draft provides mechanisms for 17 providing additional such certificates at the HTTP layer when these 18 constraints are not sufficient. 20 Many HTTP servers host content from several origins. HTTP/2 21 [RFC7540] permits clients to reuse an existing HTTP connection to a 22 server provided that the secondary origin is also in the certificate 23 provided during the TLS [I-D.ietf-tls-tls13] handshake. 25 In many cases, servers will wish to maintain separate certificates 26 for different origins but still desire the benefits of a shared HTTP 27 connection. Similarly, servers may require clients to present 28 authentication, but have different requirements based on the content 29 the client is attempting to access. 31 This document describes a how such certificates can be provided at 32 the HTTP layer to support both scenarios. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on November 18, 2016. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Server Certificate Authentication . . . . . . . . . . . . 3 69 1.2. Client Certificate Authentication . . . . . . . . . . . . 4 70 1.2.1. HTTP/1.1 using TLS 1.2 and previous . . . . . . . . . 5 71 1.2.2. HTTP/1.1 using TLS 1.3 . . . . . . . . . . . . . . . 6 72 1.2.3. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . 6 73 1.3. HTTP-Layer Certificate Authentication . . . . . . . . . . 7 74 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 75 2. Discovering Additional Certificates at the HTTP/2 Layer . . . 7 76 2.1. Indicating support for HTTP-layer certificate 77 authentication . . . . . . . . . . . . . . . . . . . . . 8 78 2.2. Making certificates or requests available . . . . . . . . 9 79 2.3. Requiring certificate authentication . . . . . . . . . . 10 80 3. Certificates Frames for HTTP/2 . . . . . . . . . . . . . . . 11 81 3.1. The CERTIFICATE_REQUIRED frame . . . . . . . . . . . . . 12 82 3.2. The USE_CERTIFICATE Frame . . . . . . . . . . . . . . . . 13 83 3.3. The CERTIFICATE_REQUEST Frame . . . . . . . . . . . . . . 14 84 3.4. The CERTIFICATE frame . . . . . . . . . . . . . . . . . . 15 85 3.4.1. Supplemental-Data . . . . . . . . . . . . . . . . . . 16 86 3.5. The CERTIFICATE_PROOF Frame . . . . . . . . . . . . . . . 17 87 4. Indicating failures during HTTP-Layer Certificate 88 Authentication . . . . . . . . . . . . . . . . . . . . . . . 18 89 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 91 6.1. Signature Methods . . . . . . . . . . . . . . . . . . . . 21 92 6.2. Supplemental Data . . . . . . . . . . . . . . . . . . . . 22 93 6.3. HTTP/2 SETTINGS_HTTP_CERT_AUTH Setting . . . . . . . . . 22 94 6.4. New HTTP/2 Frames . . . . . . . . . . . . . . . . . . . . 23 95 6.4.1. CERTIFICATE_REQUIRED . . . . . . . . . . . . . . . . 23 96 6.4.2. CERTIFICATE_REQUEST . . . . . . . . . . . . . . . . . 23 97 6.4.3. CERTIFICATE . . . . . . . . . . . . . . . . . . . . . 23 98 6.4.4. CERTIFICATE_PROOF . . . . . . . . . . . . . . . . . . 23 99 6.4.5. USE_CERTIFICATE . . . . . . . . . . . . . . . . . . . 23 100 6.5. New HTTP/2 Error Codes . . . . . . . . . . . . . . . . . 24 101 6.5.1. BAD_CERTIFICATE . . . . . . . . . . . . . . . . . . . 24 102 6.5.2. UNSUPPORTED_CERTIFICATE . . . . . . . . . . . . . . . 24 103 6.5.3. CERTIFICATE_REVOKED . . . . . . . . . . . . . . . . . 24 104 6.5.4. CERTIFICATE_EXPIRED . . . . . . . . . . . . . . . . . 24 105 6.5.5. BAD_SIGNATURE . . . . . . . . . . . . . . . . . . . . 24 106 6.5.6. CERTIFICATE_GENERAL . . . . . . . . . . . . . . . . . 25 107 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 108 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 109 8.1. Normative References . . . . . . . . . . . . . . . . . . 25 110 8.2. Informative References . . . . . . . . . . . . . . . . . 26 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 113 1. Introduction 115 HTTP clients need to know that the content they receive on a 116 connection comes from the origin that they intended to retrieve in 117 from. The traditional form of server authentication in HTTP has been 118 in the form of X.509 certificates provided during the TLS RFC5246 119 [I-D.ietf-tls-tls13] handshake. 121 Many existing HTTP [RFC7230] servers also have authentication 122 requirements for the resources they serve. Of the bountiful 123 authentication options available for authenticating HTTP requests, 124 client certificates present a unique challenge for resource-specific 125 authentication requirements because of the interaction with the 126 underlying TLS layer. 128 TLS 1.2 [RFC5246] supports one server and one client certificate on a 129 connection. These certificates may contain multiple identities, but 130 only one certificate may be provided. 132 1.1. Server Certificate Authentication 134 Section 9.1.1 of [RFC7540] describes how connections may be used to 135 make requests from multiple origins as long as the server is 136 authoritative for both. A server is considered authoritative for an 137 origin if DNS resolves the origin to the IP address of the server and 138 (for TLS) if the certificate presented by the server contains the 139 origin in the Subject Alternative Names field. 141 [I-D.ietf-httpbis-alt-svc] enables a step of abstraction from the DNS 142 resolution. If both hosts have provided an Alternative Service at 143 hostnames which resolve to the IP address of the server, they are 144 considered authoritative just as if DNS resolved the origin itself to 145 that address. However, the server's one TLS certificate is still 146 required to contain the name of each origin in question. 148 Servers which host many origins often would prefer to have separate 149 certificates for some sets of origins. This may be for ease of 150 certificate management (the ability to separately revoke or renew 151 them), due to different sources of certificates (a CDN acting on 152 behalf of multiple origins), or other factors which might drive this 153 administrative decision. Clients connecting to such origins cannot 154 currently reuse connections, even if both client and server would 155 prefer to do so. 157 Because the TLS SNI extension is exchanged in the clear, clients 158 might also prefer to retrieve certificates inside the encrypted 159 context. When this information is sensitive, it might be 160 advantageous to request a general-purpose certificate or anonymous 161 ciphersuite at the TLS layer, while acquiring the "real" certificate 162 in HTTP after the connection is established. 164 1.2. Client Certificate Authentication 166 For servers that wish to use client certificates to authenticate 167 users, they might request client authentication during or immediately 168 after the TLS handshake. However, if not all users or resources need 169 certificate-based authentication, a request for a certificate has the 170 unfortunate consequence of triggering the client to seek a 171 certificate, possibly requiring user interaction, network traffic, or 172 other time-consuming activities. During this time, the connection is 173 stalled in many implementations. Such a request can result in a poor 174 experience, particularly when sent to a client that does not expect 175 the request. 177 The TLS 1.3 CertificateRequest can be used by servers to give clients 178 hints about which certificate to offer. Servers that rely on 179 certificate-based authentication might request different certificates 180 for different resources. Such a server cannot use contextual 181 information about the resource to construct an appropriate TLS 182 CertificateRequest message during the initial handshake. 184 Consequently, client certificates are requested at connection 185 establishment time only in cases where all clients are expected or 186 required to have a single certificate that is used for all resources. 187 Many other uses for client certificates are reactive, that is, 188 certificates are requested in response to the client making a 189 request. 191 1.2.1. HTTP/1.1 using TLS 1.2 and previous 193 In HTTP/1.1, a server that relies on client authentication for a 194 subset of users or resources does not request a certificate when the 195 connection is established. Instead, it only requests a client 196 certificate when a request is made to a resource that requires a 197 certificate. TLS 1.2 [RFC5246] accomodates this by permitting the 198 server to request a new TLS handshake, in which the server will 199 request the client's certificate. 201 Figure 1 shows the server initiating a TLS-layer renegotiation in 202 response to receiving an HTTP/1.1 request to a protected resource. 204 Client Server 205 -- (HTTP) GET /protected -------------------> *1 206 <---------------------- (TLS) HelloRequest -- *2 207 -- (TLS) ClientHello -----------------------> 208 <------------------ (TLS) ServerHello, ... -- 209 <---------------- (TLS) CertificateRequest -- *3 210 -- (TLS) ..., Certificate ------------------> *4 211 -- (TLS) Finished --------------------------> 212 <-------------------------- (TLS) Finished -- 213 <--------------------------- (HTTP) 200 OK -- *5 215 Figure 1: HTTP/1.1 Reactive Certificate Authentication with TLS 1.2 217 In this example, the server receives a request for a protected 218 resource (at *1 on Figure 1). Upon performing an authorization 219 check, the server determines that the request requires authentication 220 using a client certificate and that no such certificate has been 221 provided. 223 The server initiates TLS renegotiation by sending a TLS HelloRequest 224 (at *2). The client then initiates a TLS handshake. Note that some 225 TLS messages are elided from the figure for the sake of brevity. 227 The critical messages for this example are the server requesting a 228 certificate with a TLS CertificateRequest (*3); this request might 229 use information about the request or resource. The client then 230 provides a certificate and proof of possession of the private key in 231 Certificate and CertificateVerify messages (*4). 233 When the handshake completes, the server performs any authorization 234 checks a second time. With the client certificate available, it then 235 authorizes the request and provides a response (*5). 237 1.2.2. HTTP/1.1 using TLS 1.3 239 TLS 1.3 [I-D.ietf-tls-tls13] introduces a new client authentication 240 mechanism that allows for clients to authenticate after the handshake 241 has been completed. For the purposes of authenticating an HTTP 242 request, this is functionally equivalent to renegotiation. Figure 2 243 shows the simpler exchange this enables. 245 Client Server 246 -- (HTTP) GET /protected -------------------> 247 <---------------- (TLS) CertificateRequest -- 248 -- (TLS) Certificate, CertificateVerify ----> 249 <--------------------------- (HTTP) 200 OK -- 251 Figure 2: HTTP/1.1 Reactive Certificate Authentication with TLS 1.3 253 TLS 1.3 does not support renegotiation, instead supporting direct 254 client authentication. In contrast to the TLS 1.2 example, in TLS 255 1.3, a server can simply request a certificate. 257 1.2.3. HTTP/2 259 An important part of the HTTP/1.1 exchange is that the client is able 260 to easily identify the request that caused the TLS renegotiation. 261 The client is able to assume that the next unanswered request on the 262 connection is responsible. The HTTP stack in the client is then able 263 to direct the certificate request to the application or component 264 that initiated that request. This ensures that the application has 265 the right contextual information for processing the request. 267 In HTTP/2, a client can have multiple outstanding requests. Without 268 some sort of correlation information, a client is unable to identify 269 which request caused the server to request a certificate. 271 Thus, the minimum necessary mechanism to support reactive certificate 272 authentication in HTTP/2 is an identifier that can be use to 273 correlate an HTTP request with a request for a certificate. Since 274 streams are used for individual requests, correlation with a stream 275 is sufficient. 277 [RFC7540] prohibits renegotiation after any application data has been 278 sent. This completely blocks reactive certificate authentication in 279 HTTP/2 using TLS 1.2. If this restriction were relaxed by an 280 extension or update to HTTP/2, such an identifier could be added to 281 TLS 1.2 by means of an extension to TLS. Unfortunately, many TLS 1.2 282 implementations do not permit application data to continue during a 283 renegotiation. This is problematic for a multiplexed protocol like 284 HTTP/2. 286 1.3. HTTP-Layer Certificate Authentication 288 This draft proposes bringing the TLS 1.3 CertificateRequest, 289 Certificate, and CertificateVerify messages into HTTP/2 frames, 290 enabling certificate-based authentication of both clients and servers 291 independent of TLS version. This mechanism can be implemented at the 292 HTTP layer without requiring new TLS stack behavior and without 293 breaking the existing interface between HTTP and applications above 294 it. 296 This could be done in a naive manner by replicating the messages as 297 HTTP/2 frames on each stream. However, this would create needless 298 redundancy between streams and require frequent expensive signing 299 operations. Instead, this draft lifts the bulky portions of each 300 message into frames on stream zero and permits the on-stream frames 301 to incorporate them by reference as needed. 303 Certificate chains, with proof-of-possession of the corresponding 304 private key, can be supplied into a collection of available 305 certificates. Likewise, descriptions of desired certificates can be 306 supplied into these collections. These pre-supplied elements are 307 then available for automatic use (in some situations) or for 308 reference by individual streams. 310 Section 2 describes how the feature is employed, defining means to 311 detect support in peers (Section 2.1), make certificates and requests 312 available (Section 2.2), and indicate when streams are blocked 313 waiting on an appropriate certificate (Section 2.3). Section 3 314 defines the required frame types, which parallel the TLS 1.3 message 315 exchange. Finally, Section 4 defines new error types which can be 316 used to notify peers when the exchange has not been successful. 318 1.4. Terminology 320 RFC 2119 [RFC2119] defines the terms "MUST", "MUST NOT", "SHOULD" and 321 "MAY". 323 2. Discovering Additional Certificates at the HTTP/2 Layer 325 A certificate chain is sent as a series of "CERTIFICATE" frames (see 326 Section 3.4) on stream zero. Proof of possession of the 327 corresponding private key is sent as a "CERTIFICATE_PROOF" frame (see 328 Section 3.5) on stream zero. Once the holder of a certificate has 329 sent the chain and proof, this certificate chain is cached by the 330 recipient and available for future use. If the certificate is marked 331 as "AUTOMATIC_USE", the certificate may be used by the recipient to 332 authorize any current or future request. Otherwise, the recipient 333 requests the required certificate on each stream, but the previously- 334 supplied certificates are available for reference without having to 335 resend them. 337 Likewise, the details of a request are sent on stream zero and stored 338 by the recipient. These details will be referenced by subsequent 339 "CERTIFICATE_REQUIRED" frames. 341 Data sent by each peer is correlated by the ID given in each frame. 342 This ID is unrelated to values used by the other peer, even if each 343 uses the same ID in certain cases. 345 2.1. Indicating support for HTTP-layer certificate authentication 347 Clients and servers that will accept requests for HTTP-layer 348 certificate authentication indicate this using the HTTP/2 349 "SETTINGS_HTTP_CERT_AUTH" (0xSETTING-TBD) setting. 351 The initial value for the "SETTINGS_HTTP_CERT_AUTH" setting is 0, 352 indicating that the peer does not support HTTP-layer certificate 353 authentication. If a peer does support HTTP-layer certificate 354 authentication, it uses the setting to communicate its acceptable 355 hash and signature algorithm. 357 The setting value is a pair of bitmaps. In the lower half, each set 358 bit reflects an acceptable signing algorithm for provided 359 certificates. Each bit MUST NOT be set if a proof signed in this way 360 would be unacceptable to the sender. 362 Bit 1 (0x00 00 00 01): ECDSA P-256 with SHA-256 364 Bit 2 (0x00 00 00 02): ECDSA P-384 with SHA-384 366 Bit 3 (0x00 00 00 04): Ed25519 368 Bit 4 (0x00 00 00 08): Ed448 370 Bit 5 (0x00 00 00 10): RSA-PSS with SHA-256 and MGF1 (minimum of 371 2048 bits) 373 Bits 6-16: Reserved for future use 375 If no compatible signature algorithms have been proffered in SETTINGS 376 by a peer, the frames defined in this specification MUST NOT be sent 377 to them, with the exception of empty "USE_CERTIFICATE" frames. 379 In the upper half, each set bit reflects an acceptable form of 380 supporting data to include with the certificate. 382 Bit 17 (0x00 01 00 00): Always set. Indicates the ability to 383 interpret requests for certificates. 385 Bit 18 (0x00 02 00 00): Indicates support for OCSP [RFC2560] 386 supporting data. 388 Bit 19 (0x00 04 00 00): Indicates support for Signed Certificate 389 Timestamp [RFC6962] supporting data. 391 Bit 20-32: Reserved for future use 393 2.2. Making certificates or requests available 395 When a peer has advertised support for HTTP-layer certificates as in 396 Section 2.1, either party can supply additional certificates into the 397 connection at any time. These certificates then become available for 398 the peer to consider when deciding whether a connection is suitable 399 to transport a particular request. 401 Available certificates which have the "AUTOMATIC_USE" flag set MAY be 402 used by the recipient without further notice. This means that 403 clients or servers which predict a certificate will be required could 404 pre-supply the certificate without being asked. Regardless of 405 whether "AUTOMATIC_USE" is set, these certificates are available for 406 reference by future "USE_CERTIFICATE" frames. 408 Client Server 409 <--<--<------------ (stream 0) CERTIFICATE -- 410 <-- (stream 0) CERTIFICATE_PROOF (AU flag) -- 411 ... 412 -- (stream N) GET /from-new-origin ---------> 413 <----------------------- (stream N) 200 OK -- 415 Figure 3: Server-Proffered Certificate 417 Client Server 418 -- (stream 0) CERTIFICATE ------------>-->--> 419 -- (stream 0) CERTIFICATE_PROOF (AU flag) --> 420 -- (streams 1,3) GET /protected ------------> 421 <-------------------- (streams 1,3) 200 OK -- 423 Figure 4: Client-Proffered Certificate 425 Likewise, either party can supply a certificate request that outlines 426 parameters of a certificate they might request in the future. It is 427 important to note that this does not currently request such a 428 certificate, but makes the contents of the request available for 429 reference by a future "CERTIFICATE_REQUIRED" frame. 431 Because certificates can be large and each "CERTIFICATE_PROOF" 432 requires a signing operation, the server MAY instead send an "ORIGIN" 433 frame including origins which are not in its TLS certificate. This 434 represents an explicit claim by the server to possess the appropriate 435 certificate - a claim the client MUST verify using the procedures in 436 Section 2.3 before relying on the server's authority for the claimed 437 origin. 439 2.3. Requiring certificate authentication 441 As defined in [RFC7540], when a client finds that a https:// origin 442 (or Alternative Service [I-D.ietf-httpbis-alt-svc]) to which it needs 443 to make a request has the same IP address as a server to which it is 444 already connected, it MAY check whether the TLS certificate provided 445 contains the new origin as well, and if so, reuse the connection. 447 If the TLS certificate does not contain the new origin, but the 448 server has advertised support for HTTP-layer certificates (see 449 Section 2.1, it MAY send a "CERTIFICATE_REQUIRED" frame on the stream 450 it will use to make the request. (If the request parameters have not 451 already been made available using a "CERTIFICATE_REQUEST" frame, the 452 client will need to send the "CERTIFICATE_REQUEST" in order to 453 generate the "CERTIFICATE_REQUIRED" frame.) The stream represents a 454 pending request to that origin which is blocked until a valid 455 certificate is processed. 457 The request is blocked until the server has responded with a 458 "USE_CERTIFICATE" frame pointing to a certificate for that origin. 459 If the certificate is already available, the server SHOULD 460 immediately respond with the appropriate "USE_CERTIFICATE" frame. 461 (If the certificate has not already been transmitted, the server will 462 need to make the certificate available as described in Section 2.2 463 before completing the exchange.) 465 If the server does not have the desired certificate, it MUST respond 466 with an empty "USE_CERTIFICATE" frame. In this case, or if the 467 server has not advertised support for HTTP-layer certificates, the 468 client MUST NOT send any requests for resources in that origin on the 469 current connection and SHOULD send a RST_STREAM on the stream used 470 for the request. 472 Client Server 473 <----------------------- (stream 0) ORIGIN -- 474 -- (stream 0) CERTIFICATE_REQUEST ----------> 475 ... 476 -- (stream N) CERTIFICATE_REQUIRED ---------> 477 <--<--<------------ (stream 0) CERTIFICATE -- 478 <------------ (stream 0) CERTIFICATE_PROOF -- 479 <-------------- (stream N) USE_CERTIFICATE -- 480 -- (stream N) GET /from-new-origin ---------> 481 <----------------------- (stream N) 200 OK -- 483 Figure 5: Client-Requested Certificate 485 Likewise, on each stream where certificate authentication is 486 required, the server sends a "CERTIFICATE_REQUIRED" frame, which the 487 client answers with a "USE_CERTIFICATE" frame indicating the 488 certificate to use. If the request parameters or the responding 489 certificate are not already available, they will need to be sent as 490 described in Section 2.2 as part of this exchange. 492 Client Server 493 <---------- (stream 0) CERTIFICATE_REQUEST -- 494 ... 495 -- (stream N) GET /protected ---------------> 496 <--------- (stream N) CERTIFICATE_REQUIRED -- 497 -- (stream 0) CERTIFICATE ------------>-->--> 498 -- (stream 0) CERTIFICATE_PROOF ------------> 499 -- (stream N) USE_CERTIFICATE --------------> 500 <----------------------- (stream N) 200 OK -- 502 Figure 6: Reactive Certificate Authentication 504 A server MAY push resources from an origin for which it is 505 authoritative but for which the client has not yet received the 506 certificate. In this case, the client MUST verify the server's 507 possession of an appropriate certificate by sending a 508 "CERTIFICATE_REQUIRED" frame on the pushed stream to inform the 509 server that progress is blocked until the request is satisfied. The 510 client MUST NOT use the pushed resource until an appropriate 511 certificate has been received and validated. 513 3. Certificates Frames for HTTP/2 515 The "CERTIFICATE_REQUEST" and "CERTIFICATE_REQUIRED" frames are 516 correlated by their "Request-ID" field. Subsequent 517 "CERTIFICATE_REQUIRED" frames with the same "Request-ID" value MAY be 518 sent on other streams where the sender is expecting a certificate 519 with the same parameters. 521 The "CERTIFICATE", "CERTIFICATE_PROOF", and "USE_CERTIFICATE" frames 522 are correlated by their "Cert-ID" field. Subsequent 523 "USE_CERTIFICATE" frames with the same "Cert-ID" MAY be sent in 524 response to other "CERTIFICATE_REQUIRED" frames and refer to the same 525 certificate. 527 "Request-ID" and "Cert-ID" are sender-local, and the use of the same 528 value by the other peer does not imply any correlation between their 529 frames. 531 3.1. The CERTIFICATE_REQUIRED frame 533 The "CERTIFICATE_REQUIRED" frame (0xFRAME-TBD2) is sent to indicate 534 that the HTTP request on the current stream is blocked pending 535 certificate authentication. The frame includes a request identifier 536 which can be used to correlate the stream with a previous 537 "CERTIFICATE_REQUEST" frame sent on stream zero. The 538 "CERTIFICATE_REQUEST" describes the certificate the sender requires 539 to make progress on the stream in question. 541 The "CERTIFICATE_REQUIRED" frame contains 1 octet, which is the 542 authentication request identifier, "Request-ID". A peer that 543 receives a "CERTIFICATE_REQUIRED" of any other length MUST treat this 544 as a stream error of type "PROTOCOL_ERROR". Frames with identical 545 request identifiers refer to the same "CERTIFICATE_REQUEST". 547 A server MAY send multiple "CERTIFICATE_REQUIRED" frames on the same 548 stream. If a server requires that a client provide multiple 549 certificates before authorizing a single request, each required 550 certificate MUST be indicated with a separate "CERTIFICATE_REQUIRED" 551 frame, each of which MUST have a different request identifier 552 (referencing different "CERTIFICATE_REQUEST" frames describing each 553 required certificate). To reduce the risk of client confusion, 554 servers SHOULD NOT have multiple outstanding "CERTIFICATE_REQUIRED" 555 frames on the same stream at any given time. 557 Clients MUST NOT send multiple "CERTIFICATE_REQUIRED" frames on the 558 same stream. 560 The "CERTIFICATE_REQUIRED" frame SHOULD NOT be sent to a peer which 561 has not advertised support for HTTP-layer certificate authentication. 563 The "CERTIFICATE_REQUIRED" frame MUST NOT be sent on stream zero, and 564 MUST NOT be sent on a stream in the "half-open (remote)" state. A 565 client that receives a "CERTIFICATE_REQUIRED" frame on a stream which 566 is not in a valid state SHOULD treat this as a stream error of type 567 "PROTOCOL_ERROR". 569 3.2. The USE_CERTIFICATE Frame 571 The "USE_CERTIFICATE" frame (0xFRAME-TBD5) is sent in response to a 572 "CERTIFICATE_REQUIRED" frame to indicate which certificate is being 573 used to satisfy the requirement. 575 A "USE_CERTIFICATE" frame with no payload refers to the certificate 576 provided at the TLS layer, if any. If no certificate was provided at 577 the TLS layer, the stream should be processed with no authentication, 578 likely returning an authentication-related error at the HTTP level 579 (e.g. 403) for servers or routing the request to a new connection for 580 clients. 582 Otherwise, the "USE_CERTIFICATE" frame contains the "Cert-ID" of the 583 certificate the sender wishes to use. This MUST be the ID of a 584 certificate previously presented in one or more "CERTIFICATE" frames, 585 and for which proof of possession has been presented in a 586 "CERTIFICATE_PROOF" frame. Recipients of a "USE_CERTIFICATE" frame 587 of any other length MUST treat this as a stream error of type 588 "PROTOCOL_ERROR". Frames with identical certificate identifiers 589 refer to the same certificate chain. 591 The "USE_CERTIFICATE" frame MUST NOT be sent on stream zero or a 592 stream on which a "CERTIFICATE_REQUIRED" frame has not been received. 593 Receipt of a "USE_CERTIFICATE" frame in these circmustances SHOULD be 594 treated as a stream error of type "PROTOCOL_ERROR". 596 The referenced certificate chain MUST conform to the requirements 597 expressed in the "CERTIFICATE_REQUEST" to the best of the sender's 598 ability. Specifically: 600 o If the "CERTIFICATE_REQUEST" contained a non-empty "Certificate- 601 Authorities" element, one of the certificates in the chain SHOULD 602 be signed by one of the listed CAs. 604 o If the "CERTIFICATE_REQUEST" contained a non-empty "Cert- 605 Extensions" element, the first certificate MUST match with regard 606 to the extension OIDs recognized by the sender. 608 o Each certificate that is not self-signed MUST be signed using a 609 hash/signature algorithm listed in the "Algorithms" element. 610 [[TODO: No longer exists; does SETTINGS give enough info?]] 612 If these requirements are not satisfied, the recipient MAY at its 613 discretion either return an error at the HTTP semantic layer, or 614 respond with a stream error [RFC7540] on any stream where the 615 certificate is used. Section 4 defines certificate-related error 616 codes which might be applicable. 618 3.3. The CERTIFICATE_REQUEST Frame 620 TLS 1.3 defines the "CertificateRequest" message, which prompts the 621 client to provide a certificate which conforms to certain properties 622 specified by the server. This draft defines the 623 "CERTIFICATE_REQUEST" frame (0xFRAME-TBD1), which contains the same 624 contents as a TLS 1.3 "CertificateRequest" message, but can be sent 625 over any TLS version. 627 The "CERTIFICATE_REQUEST" frame SHOULD NOT be sent to a peer which 628 has not advertised support for HTTP-layer certificate authentication. 630 The "CERTIFICATE_REQUEST" frame MUST be sent on stream zero. A 631 "CERTIFICATE_REQUEST" frame received on any other stream MUST be 632 rejected with a stream error of type "PROTOCOL_ERROR". 634 0 1 2 3 635 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 636 +-------------------------------+---------------+---------------+ 637 | Request-ID (8)| CA-Count (16) | 638 +-----------------------------------------------+---------------+ 639 | Certificate-Authorities (?) ... 640 +---------------------------------------------------------------+ 641 | Cert-Extension-Count (16) | Cert-Extensions(?) ... 642 +---------------------------------------------------------------+ 644 Figure 7: CERTIFICATE_REQUEST frame payload 646 The frame contains the following fields: 648 Request-ID: "Request-ID" is an 8-bit opaque identifier used to 649 correlate subsequent certificate-related frames with this request. 650 The identifier MUST be unique in the session for the sender. 652 CA-Count and Certificate-Authorities: "Certificate-Authorities" is a 653 series of distinguished names of acceptable certificate 654 authorities, represented in DER-encoded [X690] format. These 655 distinguished names may specify a desired distinguished name for a 656 root CA or for a subordinate CA; thus, this message can be used to 657 describe known roots as well as a desired authorization space. 658 The number of such structures is given by the 16-bit "CA-Count" 659 field, which MAY be zero. If the "CA-Count" field is zero, then 660 the recipient MAY send any certificate that meets the rest of the 661 selection criteria in the "CERTIFICATE_REQUEST", unless there is 662 some external arrangement to the contrary. 664 Cert-Extension-Count and Cert-Extensions: A list of certificate 665 extension OIDs [RFC5280] with their allowed values, represented in 666 a series of "CertificateExtension" structures (see 667 [I-D.ietf-tls-tls13] section 6.3.5). The list of OIDs MUST be 668 used in certificate selection as described in 669 [I-D.ietf-tls-tls13]. The number of Cert-Extension structures is 670 given by the 16-bit "Cert-Extension-Count" field, which MAY be 671 zero. 673 Some certificate extension OIDs allow multiple values (e.g. Extended 674 Key Usage). If the sender has included a non-empty Cert-Extensions 675 list, the certificate MUST contain all of the specified extension 676 OIDs that the recipient recognizes. For each extension OID 677 recognized by the recipient, all of the specified values MUST be 678 present in the certificate (but the certificate MAY have other values 679 as well). However, the recipient MUST ignore and skip any 680 unrecognized certificate extension OIDs. 682 Servers MUST be able to recognize the "subjectAltName" extension 683 ([RFC2459] section 4.2.1.7) at a minimum. Clients MUST always 684 specify the desired origin using this extension, though other 685 extensions MAY also be included. 687 PKIX RFCs define a variety of certificate extension OIDs and their 688 corresponding value types. Depending on the type, matching 689 certificate extension values are not necessarily bitwise-equal. It 690 is expected that implementations will rely on their PKI libraries to 691 perform certificate selection using these certificate extension OIDs. 693 3.4. The CERTIFICATE frame 695 A certificate chain is transferred as a series of "CERTIFICATE" 696 frames (0xFRAME-TBD3) with the same Cert-ID, each containing a single 697 certificate in the chain. The end certificate of the chain can be 698 used as authentication for previous or subsequent requests. 700 The "CERTIFICATE" frame defines no flags. 702 While unlikely, it is possible that an exceptionally large 703 certificate might be too large to fit in a single HTTP/2 frame (see 704 [RFC7540] section 4.2). Senders unable to transfer a requested 705 certificate due to the recipient's "SETTINGS_MAX_FRAME_SIZE" value 706 SHOULD terminate affected streams with "CERTIFICATE_TOO_LARGE". 708 The "CERTIFICATE" frame MUST be sent on stream zero. A "CERTIFICATE" 709 frame received on any other stream MUST be rejected with a stream 710 error of type "PROTOCOL_ERROR". 712 0 1 2 3 713 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 714 +-------------------------------+-------------------------------+ 715 | Cert-ID (8) | SData-Count(8)| SData-Records (*) ... 716 +---------------------------------------------------------------+ 717 | Certificate (*) ... 718 +---------------------------------------------------------------+ 720 Figure 8: CERTIFICATE frame payload 722 The fields defined by the "CERTIFICATE" frame are: 724 Cert-ID: The sender-assigned ID of the certificate chain. 726 SData-Count and SData-Records: An array of Supplemental-Data objects 727 (see Section 3.4.1), with the number given by SData-Count, which 728 MAY be zero. Each Supplemental-Data object contains information 729 about the certificate. 731 Certificate: An X.509v3 [RFC5280] certificate in the sender's 732 certificate chain. 734 The first or only "CERTIFICATE" frame with a given Cert-ID MUST 735 contain the sender's certificate. Each subsequent certificate SHOULD 736 directly certify the certificate immediately preceding it. A 737 certificate which specifies a trust anchor MAY be omitted, provided 738 that the recipient is known to already possess the relevant 739 certificate. (For example, because it was included in a 740 "CERTIFICATE_REQUEST"'s Certificate-Authorities list.) 742 3.4.1. Supplemental-Data 744 Supplemental data helps a client to validate a certificate, but is 745 not essential to doing so. Peers SHOULD NOT include supplemental 746 data which the recipient is known not to support, but MAY offer 747 supplemental data prior to learning which types the recipient 748 supports. 750 Each supplemental data object has the following format: 752 0 1 2 3 753 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 754 +-------------------------------+-------------------------------+ 755 | Type(8) | Length (16) | Data (*) ... 756 +---------------------------------------------------------------+ 758 Figure 9: Supplemental-Data element 760 The Type field indicates which type of supplemental data is being 761 offered: 763 OSCP (0x0): Data contains an OCSP [RFC2560] record supporting this 764 certificate. 766 SCT (0x1): Data contains a Signed Certificate Timestamp [RFC6962] 767 supporting this certificate. 769 Other values (0x3-0xF): Reserved for future use. 771 3.5. The CERTIFICATE_PROOF Frame 773 The "CERTIFICATE_PROOF" frame proves possession of the private key 774 corresponding to an end certificate previously shown in a 775 "CERTIFICATE" frame. 777 The "CERTIFICATE_PROOF" frame defines one flag: 779 AUTOMATIC_USE (0x01): Indicates that the certificate can be used 780 automatically on future requests. 782 0 1 2 3 783 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 784 +-------------------------------+-------------------------------+ 785 | Cert-ID (8) | Algorithm (16) | Signature(*)... 786 +---------------------------------------------------------------+ 788 Figure 10: CERTIFICATE_PROOF frame payload 790 The "CERTIFICATE_PROOF" frame (0xFRAME-TBD4) contains an "Algorithm" 791 field (a "SignatureAndHashAlgorithm", from [I-D.ietf-tls-tls13] 792 section 6.3.2.1), describing the hash/signature algorithm pair being 793 used. [[TODO: Sixteen bits because it is in TLS 1.3; if we're using 794 a bitmask to express allowed values, we're down to ~5 bits needed to 795 contain all permitted algorithms. Shrink?]] 796 The signature is performed as described in [I-D.ietf-tls-tls13], with 797 the following values being used: 799 o The context string for the signature is "HTTP/2 CERTIFICATE_PROOF" 801 o The "specified content" is an [RFC5705] exported value, with the 802 following parameters: 804 * Disambiguating label string: "EXPORTER HTTP/2 805 CERTIFICATE_PROOF" 807 * Length: 64 bytes 809 Because the exported value can be independently calculated by both 810 sides of the TLS connection, the value to be signed is not sent on 811 the wire at any time. The same signed value is used for all 812 "CERTIFICATE_PROOF" frames in a single HTTP/2 connection. 814 A "CERTIFICATE_PROOF" frame MUST be sent only after all "CERTIFICATE" 815 frames with the same Cert-ID have been sent, and MUST correspond to 816 the first certificate presented in the first "CERTIFICATE" frame with 817 that Cert-ID. Receipt of multiple "CERTIFICATE_PROOF" frames for the 818 same Cert-ID, receipt of a "CERTIFICATE_PROOF" frame without a 819 corresponding "CERTIFICATE" frame, or receipt of a "CERTIFICATE" 820 frame after a corresponding "CERTIFICATE_PROOF" MUST be treated as a 821 session error of type "PROTOCOL_ERROR". 823 If the "AUTOMATIC_USE" flag is set, the recipient MAY omit sending 824 "CERTIFICATE_REQUIRED" frames on future streams which would require a 825 similar certificate and use the referenced certificate for 826 authentication without further notice to the holder. This behavior 827 is optional, and receipt of a "CERTIFICATE_REQUIRED" frame does not 828 imply that previously-presented certificates were unacceptable, even 829 if "AUTOMATIC_USE" was set. Servers MUST set the "AUTOMATIC_USE" 830 flag when sending a "CERTIFICATE_PROOF" frame. A server MUST NOT 831 send certificates for origins which it is not prepared to service on 832 the current connection. 834 4. Indicating failures during HTTP-Layer Certificate Authentication 836 Because this draft permits certificates to be exchanged at the HTTP 837 framing layer instead of the TLS layer, several certificate-related 838 errors which are defined at the TLS layer might now occur at the HTTP 839 framing layer. In this section, those errors are restated and added 840 to the HTTP/2 error code registry. 842 BAD_CERTIFICATE (0xERROR-TBD1): A certificate was corrupt, contained 843 signatures that did not verify correctly, etc. 845 UNSUPPORTED_CERTIFICATE (0xERROR-TBD2): A certificate was of an 846 unsupported type or did not contain required extensions 848 CERTIFICATE_REVOKED (0xERROR-TBD3): A certificate was revoked by its 849 signer 851 CERTIFICATE_EXPIRED (0xERROR-TBD4): A certificate has expired or is 852 not currently valid 854 BAD_SIGNATURE (0xERROR-TBD5): The digital signature provided did not 855 match the claimed public key 857 CERTIFICATE_TOO_LARGE (0xERROR-TBD6): The certificate cannot be 858 transferred due to the recipient's "SETTINGS_MAX_FRAME_SIZE" 860 CERTIFICATE_GENERAL (0xERROR-TBD7): Any other certificate-related 861 error 863 As described in [RFC7540], implementations MAY choose to treat a 864 stream error as a connection error at any time. Of particular note, 865 a stream error cannot occur on stream 0, which means that 866 implementations cannot send non-session errors in response to 867 "CERTIFICATE_REQUEST", "CERTIFICATE", and "CERTIFICATE_PROOF" frames. 868 Implementations which do not wish to terminate the connection MAY 869 either send relevant errors on any stream which references the 870 failing certificate in question or process the requests as 871 unauthenticated and provide error information at the HTTP semantic 872 layer. 874 5. Security Considerations 876 This mechanism defines an alternate way to obtain server and client 877 certificates other than the TLS handshake. While the signature of 878 exporter values is expected to be equally secure, it is important to 879 recognize that a vulnerability in this code path is at least equal to 880 a vulnerability in the TLS handshake. 882 This could also increase the impact of a key compromise. Rather than 883 needing to subvert DNS or IP routing in order to use a compromised 884 certificate, a malicious server now only needs a client to connect to 885 _some_ HTTPS site under its control. Clients SHOULD continue to 886 validate that destination IP addresses are valid for the origin 887 either by direct DNS resolution or resolution of a validated 888 Alternative Service. (Future work could include a mechanism for a 889 server to offer proofs.) 891 This draft defines a mechanism which could be used to probe servers 892 for origins they support, but opens no new attack versus making 893 repeat TLS connections with different SNI values. Servers SHOULD 894 impose similar denial-of-service mitigations (e.g. request rate 895 limits) to "CERTIFICATE_REQUEST" frames as to new TLS connections. 897 While the "CERTIFICATE_REQUEST" frame permits the sender to enumerate 898 the acceptable Certificate Authorities for the requested certificate, 899 it might not be prudent (either for security or data consumption) to 900 include the full list of trusted Certificate Authorities in every 901 request. Senders, particularly clients, are advised to send an empty 902 "Certificate-Authorities" element unless they are expecting a 903 certificate to be signed by a particular CA or small set of CAs. 905 Failure to provide a certificate on a stream after receiving 906 "CERTIFICATE_REQUIRED" blocks processing, and SHOULD be subject to 907 standard timeouts used to guard against unresponsive peers. 909 In order to protect the privacy of the connection against triple- 910 handshake attacks, this feature of HTTP/2 MUST be used only over TLS 911 1.3 or greater, or over TLS 1.2 in combination with the Extended 912 Master Secret extension defined in [RFC7627]. 914 Client implementations need to carefully consider the impact of 915 setting the "AUTOMATIC_USE" flag. This flag is a performance 916 optimization, permitting the client to avoid a round-trip on each 917 request where the server checks for certificate authentication. 918 However, once this flag has been sent, the client has zero knowledge 919 about whether the server will use the referenced cert for any future 920 request, or even for an existing request which has not yet completed. 921 Clients MUST NOT set this flag on any certificate which is not 922 appropriate for currently-in-flight requests, and MUST NOT make any 923 future requests on the same connection which they are not willing to 924 have associated with the provided certificate. 926 Implementations need to be aware of the potential for confusion about 927 the state of a connection. The presence or absence of a validated 928 certificate can change during the processing of a request, 929 potentially multiple times, as "USE_CERTIFICATE" frames are received. 930 A server that uses certificate authentication needs to be prepared to 931 reevaluate the authorization state of a request as the set of 932 certificates changes. 934 Finally, validating a multitude of signatures can be computationally 935 expensive, while generating an invalid signature is computationally 936 cheap. Implementations will require checks against attacks from this 937 direction. Signature proofs SHOULD NOT be validated until a stream 938 requires the certificate to make progress. A signature which is not 939 valid based on the asserted public key SHOULD be treated as a session 940 error, to avoid further attacks from the peer, though an 941 implementation MAY instead disable HTTP-layer certificates for the 942 current connection instead. 944 6. IANA Considerations 946 This draft establishes two new registries, and adds entries in three 947 others. 949 Acceptable signature methods are registered in Section 6.1. 950 Acceptable forms of supplemental data are registered in Section 6.2. 952 The HTTP/2 "SETTINGS_HTTP_CERT_AUTH" setting is registered in 953 Section 6.3. Five frame types are registered in Section 6.4. Six 954 error codes are registered in Section 6.5. 956 6.1. Signature Methods 958 This document establishes a registry for signature methods acceptable 959 for use with this extension. The "HTTP-Layer Certificate Signature 960 Method" registry manages a space of sixteen values. The "HTTP-Layer 961 Certificate Signature Method" operates under either the "RFC 962 Required" or "IESG Approval" policy. 964 New entries in this registry require the following information: 966 Signature Method: A name or label for the signature method 968 Bit assignment: A single-bit value from 0x0000 to 0x8000 970 Specification: A document which describes how the signature may be 971 performed 973 The entries in the following table are registered by this document. 975 +-------------------------------+------------+------------------------------+ 976 | Signature Method | Bit | Specification | 977 +-------------------------------+------------+------------------------------+ 978 | ECDSA P-256 with SHA-256 | 1 (0x0001) | [FIPS-186-4] | 979 | ECDSA P-384 with SHA-384 | 2 (0x0002) | [FIPS-186-4] | 980 | Ed25519 | 3 (0x0004) | [I-D.josefsson-eddsa-ed25519]| 981 | Ed448 | 4 (0x0008) | [I-D.josefsson-eddsa-ed25519]| 982 | RSA-PSS with SHA-256 and MGF1 | 5 (0x0010) | [PKCS.1] | 983 +-------------------------------+------------+------------------------------+ 985 Figure 11 987 6.2. Supplemental Data 989 This document establishes a registry for supplemental data types 990 acceptable for use with this extension. The "HTTP-Layer Certificate 991 Supplemental Data" registry manages a space of sixteen values. The 992 "HTTP-Layer Certificate Supplemental Data" operates under either the 993 "RFC Required" or "IESG Approval" policy. 995 New entries in this registry require the following information: 997 Data Type: A name or label for the supplemental data type 999 Bit assignment: A single-bit value from 0x0000 to 0x8000 1001 Value assignment: A value in the range 0x00 to 0xFF; one type MAY 1002 reserve multiple values 1004 Specification: A document which describes how the supplemental data 1005 may be interpreted 1007 The entries in the following table are registered by this document. 1009 +------------------------+------------+-------+----------------------+ 1010 | Data Type | Bit | Value | Specification | 1011 +------------------------+------------+-------+----------------------+ 1012 | Reserved | 1 (0x0001) | N/A | {{setting}} | 1013 | OCSP | 2 (0x0002) | 0x00 | [RFC2560] | 1014 | SCT | 3 (0x0004) | 0x01 | [RFC6962] | 1015 +------------------------+------------+------------------------------+ 1017 Figure 12 1019 6.3. HTTP/2 SETTINGS_HTTP_CERT_AUTH Setting 1021 The SETTINGS_HTTP_CERT_AUTH setting is registered in the "HTTP/2 1022 Settings" registry established in [RFC7540]. 1024 Name: SETTINGS_HTTP_CERT_AUTH 1026 Code: 0xSETTING-TBD 1028 Initial Value: 0 1030 Specification: This document. 1032 6.4. New HTTP/2 Frames 1034 Four new frame types are registered in the "HTTP/2 Frame Types" 1035 registry established in [RFC7540]. 1037 6.4.1. CERTIFICATE_REQUIRED 1039 Frame Type: CERTIFICATE_REQUIRED 1041 Code: 0xFRAME-TBD1 1043 Specification: This document. 1045 6.4.2. CERTIFICATE_REQUEST 1047 Frame Type: CERTIFICATE_REQUEST 1049 Code: 0xFRAME-TBD2 1051 Specification: This document. 1053 6.4.3. CERTIFICATE 1055 Frame Type: CERTIFICATE 1057 Code: 0xFRAME-TBD3 1059 Specification: This document. 1061 6.4.4. CERTIFICATE_PROOF 1063 Frame Type: CERTIFICATE_PROOF 1065 Code: 0xFRAME-TBD4 1067 Specification: This document. 1069 6.4.5. USE_CERTIFICATE 1071 Frame Type: USE_CERTIFICATE 1073 Code: 0xFRAME-TBD5 1075 Specification: This document. 1077 6.5. New HTTP/2 Error Codes 1079 Five new error codes are registered in the "HTTP/2 Error Code" 1080 registry established in [RFC7540]. 1082 6.5.1. BAD_CERTIFICATE 1084 Name: BAD_CERTIFICATE 1086 Code: 0xERROR-TBD1 1088 Specification: This document. 1090 6.5.2. UNSUPPORTED_CERTIFICATE 1092 Name: UNSUPPORTED_CERTIFICATE 1094 Code: 0xERROR-TBD2 1096 Specification: This document. 1098 6.5.3. CERTIFICATE_REVOKED 1100 Name: CERTIFICATE_REVOKED 1102 Code: 0xERROR-TBD3 1104 Specification: This document. 1106 6.5.4. CERTIFICATE_EXPIRED 1108 Name: CERTIFICATE_EXPIRED 1110 Code: 0xERROR-TBD4 1112 Specification: This document. 1114 6.5.5. BAD_SIGNATURE 1116 Name: BAD_SIGNATURE 1118 Code: 0xERROR-TBD5 1120 Specification: This document. 1122 6.5.6. CERTIFICATE_GENERAL 1124 Name: CERTIFICATE_GENERAL 1126 Code: 0xERROR-TBD6 1128 Specification: This document. 1130 7. Acknowledgements 1132 Eric Rescorla pointed out several failings in an earlier revision. 1133 Andrei Popov contributed to the TLS considerations. 1135 8. References 1137 8.1. Normative References 1139 [I-D.ietf-tls-tls13] 1140 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1141 Version 1.3", draft-ietf-tls-tls13-12 (work in progress), 1142 March 2016. 1144 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1145 Requirement Levels", BCP 14, RFC 2119, 1146 DOI 10.17487/RFC2119, March 1997, 1147 . 1149 [RFC2459] Housley, R., Ford, W., Polk, W., and D. Solo, "Internet 1150 X.509 Public Key Infrastructure Certificate and CRL 1151 Profile", RFC 2459, DOI 10.17487/RFC2459, January 1999, 1152 . 1154 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1155 (TLS) Protocol Version 1.2", RFC 5246, 1156 DOI 10.17487/RFC5246, August 2008, 1157 . 1159 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1160 Housley, R., and W. Polk, "Internet X.509 Public Key 1161 Infrastructure Certificate and Certificate Revocation List 1162 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1163 . 1165 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1166 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1167 March 2010, . 1169 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1170 Protocol (HTTP/1.1): Message Syntax and Routing", 1171 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1172 . 1174 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1175 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1176 DOI 10.17487/RFC7540, May 2015, 1177 . 1179 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 1180 Langley, A., and M. Ray, "Transport Layer Security (TLS) 1181 Session Hash and Extended Master Secret Extension", 1182 RFC 7627, DOI 10.17487/RFC7627, September 2015, 1183 . 1185 [X690] ITU-T, "Information technology - ASN.1 encoding Rules: 1186 Specification of Basic Encoding Rules (BER), Canonical 1187 Encoding Rules (CER) and Distinguished Encoding Rules 1188 (DER)", ISO ISO/IEC 8825-1:2002, 2002, 1189 . 1192 8.2. Informative References 1194 [FIPS-186-4] 1195 National Institute of Standards and Technology, "Digital 1196 Signature Standard (DSS)", FIPS 186-4, July 2013, 1197 . 1200 [I-D.ietf-httpbis-alt-svc] 1201 Nottingham, M., McManus, P., and J. Reschke, "HTTP 1202 Alternative Services", draft-ietf-httpbis-alt-svc-14 (work 1203 in progress), March 2016. 1205 [I-D.josefsson-eddsa-ed25519] 1206 Josefsson, S. and N. Moller, "EdDSA and Ed25519", draft- 1207 josefsson-eddsa-ed25519-03 (work in progress), May 2015. 1209 [I-D.nottingham-httpbis-origin-frame] 1210 Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame", 1211 draft-nottingham-httpbis-origin-frame-01 (work in 1212 progress), January 2016. 1214 [PKCS.1.1991] 1215 RSA Laboratories, "RSA Encryption Standard, Version 1.1", 1216 PKCS 1, June 1991. 1218 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1219 Adams, "X.509 Internet Public Key Infrastructure Online 1220 Certificate Status Protocol - OCSP", RFC 2560, 1221 DOI 10.17487/RFC2560, June 1999, 1222 . 1224 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 1225 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 1226 . 1228 Authors' Addresses 1230 Mike Bishop 1231 Microsoft 1233 Email: michael.bishop@microsoft.com 1235 Martin Thomson 1236 Mozilla 1238 Email: martin.thomson@gmail.com