idnits 2.17.1 draft-ietf-tls-multiple-cert-status-extension-08.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 is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 12, 2013) is 4003 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'This RFC' is mentioned on line 340, but not defined == Outdated reference: A later version (-20) exists of draft-ietf-pkix-rfc2560bis-17 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2560 (Obsoleted by RFC 6960) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Pettersen 3 Internet-Draft April 12, 2013 4 Intended status: Standards Track 5 Expires: October 14, 2013 7 The TLS Multiple Certificate Status Request Extension 8 draft-ietf-tls-multiple-cert-status-extension-08 10 Abstract 12 This document defines the Transport Layer Security (TLS) Certificate 13 Status Version 2 Extension to allow clients to specify and support 14 several certificate status methods. (The use of the Certificate 15 Status extension is commonly referred to as "OCSP stapling".) Also 16 defined is a new method based on the Online Certificate Status 17 Protocol (OCSP) that servers can use to provide status information 18 not just about the server's own certificate, but also the status of 19 intermediate certificates in the chain. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 14, 2013. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 1. Introduction 67 The Transport Layer Security (TLS) Extension [RFC6066] framework 68 defines, among other extensions, the Certificate Status Extension 69 (also referred to as "OCSP stapling") that clients can use to request 70 the server's copy of the current status of its certificate. The 71 benefits of this extension include a reduced number of roundtrips and 72 network delays for the client to verify the status of the server's 73 certificate and a reduced load on the certificate issuer's status 74 response servers, thus solving a problem that can become significant 75 when the issued certificate is presented by a frequently visited 76 server. 78 There are two problems with the existing Certificate Status 79 extension. First, it does not provide functionality to request the 80 status information about intermediate Certification Authority (CA) 81 certificates, which means the client has to request status 82 information through other methods, such as Certificate Revocation 83 Lists (CRLs), introducing further delays. Second, the current format 84 of the extension and requirements in the TLS protocol prevents a 85 client from offering the server multiple status methods. 87 Many CAs are now issuing intermediate CA certificates that not only 88 specify the publication point for their CRLs in a CRL Distribution 89 Point [RFC5280], but also specify a URL for their OCSP 90 [I-D.ietf-pkix-rfc2560bis] server in Authority Information Access 91 [RFC5280]. Given that client-cached CRLs are frequently out of date, 92 clients would benefit from using OCSP to access up-to-date status 93 information about intermediate CA certificates. The benefit to the 94 issuing CA is less clear, as providing the bandwidth for the OCSP 95 responder can be costly, especially for CAs with many high-traffic 96 subscriber sites, and this cost is a concern for many CAs. There are 97 cases where OCSP requests for a single high-traffic site caused 98 significant network problems for the issuing CA. 100 Clients will benefit from the TLS server providing certificate status 101 information regardless of type, not just for the server certificate, 102 but also for the intermediate CA certificates. Combining the status 103 checks into one extension will reduce the roundtrips needed to 104 complete the handshake by the client to just those needed for 105 negotiating the TLS connection. Also, for the Certification 106 Authorities, the load on their servers will depend on the number of 107 certificates they have issued, not on the number of visitors to those 108 sites. Additionally, using this extension significantly reduces 109 privacy concerns around the clients informing the Certificate Issuer 110 about which sites they are visiting. 112 For such a new system to be introduced seamlessly, clients need to be 113 able to indicate support for the existing OCSP Certificate Status 114 method, and a new multiple-OCSP mode. 116 Unfortunately, the definition of the Certificate Status extension 117 only allows a single Certificate Status extension to be defined in a 118 single extension record in the handshake, and the TLS Protocol 119 [RFC5246] only allows a single record in the extension list for any 120 given extension. This means that it is not possible for clients to 121 indicate support for new methods while still supporting older 122 methods, which would cause problems for interoperability between 123 newer clients and older servers. This will not just be an issue for 124 the multiple status request mode proposed above, but also for any 125 other future status methods that might be introduced. This will be 126 true not just for the current PKIX infrastructure [RFC5280], but also 127 for alternative PKI structures. 129 The solution to this problem is to define a new extension, 130 status_request_v2, with an extended format that allows the client to 131 indicate support for multiple status request methods. This is 132 implemented using a list of CertificateStatusRequestItemV2 records in 133 the extension record. As the server will select the single status 134 method based on the selected cipher suite and the certificate 135 presented, no significant changes are needed in the server's 136 extension format. 138 1.1. Requirements Language 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 1.2. Presentation language 146 This document defines protocol structures using the same conventions 147 and presentation language as defined in Section 4 of [RFC5246]. 149 2. Multiple Certificate Status Extension 151 2.1. New extension 153 The extension defined by this document is indicated by the 154 "status_request_v2" in the ExtensionType enum (originally defined by 155 [RFC6066]), which uses the following value: 157 enum { 158 status_request_v2(XX), (65535) 159 } ExtensionType; 161 [[ EDITOR: The value used for status_request_v2 has been left as 162 "XX". This value will be assigned when this draft progresses to 163 RFC.]] 165 2.2. Multiple Certificate Status Request record 167 Clients that support a certificate status protocol like OCSP may send 168 the status_request_v2 extension to the server in order to use the TLS 169 handshake to transfer such data instead of downloading it through 170 separate connections. When using this extension, the 171 "extension_data" field (defined by Section 7.4.1.4 in[RFC5246]) of 172 the extension SHALL contain a CertificateStatusRequestListV2 where: 174 struct { 175 CertificateStatusType status_type; 176 uint16 request_length; /* Length of request field in bytes */ 177 select (status_type) { 178 case ocsp: OCSPStatusRequest; 179 case ocsp_multi: OCSPStatusRequest; 180 } request; 181 } CertificateStatusRequestItemV2; 183 enum { ocsp(1), ocsp_multi(2), (255) } CertificateStatusType; 185 struct { 186 ResponderID responder_id_list<0..2^16-1>; 187 Extensions request_extensions; 188 } OCSPStatusRequest; 190 opaque ResponderID<1..2^16-1>; 191 opaque Extensions<0..2^16-1>; 193 struct { 194 CertificateStatusRequestItemV2 certificate_status_req_list<1..2^16-1>; 195 } CertificateStatusRequestListV2; 197 In the OCSPStatusRequest (originally defined by [RFC6066]), the 198 "ResponderID" provides a list of OCSP responders that the client 199 trusts. A zero-length "responder_id_list" sequence has the special 200 meaning that the responders are implicitly known to the server, e.g., 201 by prior arrangement, or are identfied by the certificates used by 202 the server. "Extensions" is a DER encoding [CCITT.X690.2002] of the 203 OCSP request extensions, and if the server supports forwarding of 204 OCSP request extensions, this value MUST be forwarded without 205 modification. 207 Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as 208 defined in [I-D.ietf-pkix-rfc2560bis]. "Extensions" is imported from 209 [RFC5280]. A zero-length "request_extensions" value means that there 210 are no extensions (as opposed to a DER-encoded zero-length ASN.1 211 SEQUENCE, which is not valid for the "Extensions" type). 213 Servers that supports clients' selection of responders using the 214 ResponderID field could implement this selection by matching the 215 responder ID valuesfrom the client's list with the ResponderIDs of 216 known OCSP responders, either by using a binary compare of the 217 values, or a hash calculation and compare method. 219 In the case of the "id-pkix-ocsp-nonce" OCSP extension, [RFC2560] is 220 unclear about its encoding; for clarification, the nonce MUST be a 221 DER-encoded OCTET STRING, which is encapsulated as another OCTET 222 STRING (note that implementations based on an existing OCSP client 223 will need to be checked for conformance to this requirement). This 224 has been clarified in [I-D.ietf-pkix-rfc2560bis]. 226 The items in the list of CertificateStatusRequestItemV2 entries are 227 in order of the client's preference (favorite choice first). 229 A server that receives a client hello containing the 230 "status_request_v2" extension MAY return a suitable certificate 231 status response message to the client along with the server's 232 certificate message. If OCSP is requested, it SHOULD use the 233 information contained in the extension when selecting an OCSP 234 responder and SHOULD include request_extensions in the OCSP request. 236 The server returns a certificate status response along with its 237 certificate by sending a "CertificateStatus" message (originally 238 defined by [RFC6066]) immediately after the [RFC5246] (Section 7.4.2) 239 "Certificate" message (and before any "ServerKeyExchange" or 240 "CertificateRequest" messages). If a server returns a 241 "CertificateStatus" message in response to a status_request_v2 242 request, then the server MUST have included an extension of type 243 "status_request_v2" with empty "extension_data" in the extended 244 server hello. The "CertificateStatus" message is conveyed using the 245 handshake message type "certificate_status" (defined in [RFC6066]) as 246 follows (updated from the definition in [RFC6066]): 248 struct { 249 CertificateStatusType status_type; 250 select (status_type) { 251 case ocsp: OCSPResponse; 252 case ocsp_multi: OCSPResponseList; 253 } response; 254 } CertificateStatus; 256 opaque OCSPResponse<0..2^24-1>; 258 struct { 259 OCSPResponse ocsp_response_list<1..2^24-1>; 260 } OCSPResponseList; 262 An "OCSPResponse" element (originally defined by [RFC6066]) contains 263 a complete, DER-encoded OCSP response (using the ASN.1 264 [CCITT.X680.2002] type OCSPResponse defined in 265 [I-D.ietf-pkix-rfc2560bis]). Only one OCSP response, with a length 266 of at least one byte, may be sent for status_type "ocsp". 268 An "ocsp_response_list" contains a list of "OCSPResponse" elements, 269 as specified above, each containing the OCSP response for the 270 matching corresponding certificate in the server's Certificate TLS 271 handshake message. That is, the first entry is the OCSP response for 272 the first certificate in the Certificate list, the second entry is 273 the response for the second certificate, and so on. The list MAY 274 contain fewer OCSP responses than there were certificates in the 275 Certificate handshake message, but there MUST NOT be more responses 276 than there were certificates in the list. Individual elements of the 277 list MAY have a length of 0 (zero) bytes, if the server does not have 278 the OCSP response for that particular certificate stored, in which 279 case, the client MUST act as if a response was not received for that 280 particular certificate. If the client receives a 281 "ocsp_response_list" that does not contain a response for one or more 282 of the certificates in the completed certificate chain, the client 283 SHOULD attempt to validate the certificate using an alternative 284 retrieval method, such as downloading the relevant CRL; OCSP SHOULD 285 in this situation only be used for the end entity certificate, not 286 intermediate CA certificates, for reasons stated above. 288 Note that a server MAY also choose not to send a "CertificateStatus" 289 message, even if it has received a "status_request_v2" extension in 290 the client hello message and has sent a "status_request_v2" extension 291 in the server hello message. Additionally, note that that a server 292 MUST NOT send the "CertificateStatus" message unless it received 293 either a "status_request" or "status_request_v2" extension in the 294 client hello message and sent a corresponding "status_request" or 295 "status_request_v2" extension in the server hello message. 297 Clients requesting an OCSP response and receiving one or more OCSP 298 responses in a "CertificateStatus" message MUST check the OCSP 299 response(s) and abort the handshake if the response is a revoked 300 status or other unacceptable responses (as determined by client 301 policy), with a bad_certificate_status_response(113) alert. This 302 alert is always fatal. 304 If the OCSP response received from the server does not result in a 305 definite "good" or "revoked" status, it is inconclusive. A TLS 306 client in such a case MAY check the validity of the server 307 certificate through other means, e.g., by directly querying the 308 certificate issuer. If such processing still results in an 309 inconclusive response, then the application using the TLS connection 310 will have to decide whether to close the connection or not. Note 311 that this problem cannot be decided by the generic TLS client code 312 without information from the application. If the application doesn't 313 provide any such information, then the client MUST abort the 314 connection since the server certificate has not been sufficiently 315 validated. 317 An example of where the application might wish to continue is with 318 EAP-TLS, where the application can use another mechanism to check the 319 status of a certificate once it obtains network access. In this 320 case, the application could have the client continue with the 321 handshake, but it MUST NOT disclose a username and password until it 322 has fully validated the server certificate. 324 3. IANA Considerations 326 Section 2.1 defines the new TLS Extension status_request_v2 enum, 327 which should be added to the ExtensionType Values list in the IANA 328 Transport Layer Security (TLS) Extensions registry. 330 Section 2.2 describes a TLS CertificateStatusType Registry to be 331 maintained by the IANA. The new registry is called TLS Certificate 332 Status Types and should be defined under the Transport Layer Security 333 (TLS) Extensions registry. CertificateStatusType values are to be 334 assigned via IETF Review as defined in [RFC5226]. The initial 335 registry corresponds to the definition of "ExtensionType" in 336 Section 2.2. 338 Value Description Reference 339 1 ocsp [This RFC] 340 2 ocsp_multi [This RFC] 342 4. Security Considerations 344 General Security Considerations for TLS Extensions are covered in 345 [RFC5246]. Security Considerations for the particular extension 346 specified in this document are given below. In general, implementers 347 should continue to monitor the state of the art and address any 348 weaknesses identified. 350 4.1. Security Considerations for status_request_v2 352 If a client requests an OCSP response, it must take into account that 353 an attacker's server using a compromised key could (and probably 354 would) pretend not to support the extension. In this case, a client 355 that requires OCSP validation of certificates SHOULD either contact 356 the OCSP server directly or abort the handshake. 358 Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may 359 improve security against attacks that attempt to replay OCSP 360 responses; see Section 4.4.1 of [I-D.ietf-pkix-rfc2560bis] for 361 further details. 363 This extension allow the client to send arbitrary data to the server. 364 The server implementers need to handle such data carefully to avoid 365 introducing security vulnerabilities. 367 The security considerations of [I-D.ietf-pkix-rfc2560bis] apply to 368 OCSP requests and responses. 370 5. Acknowledgements 372 This document is based on [RFC6066] authored by Donald Eastlake 3rd. 374 6. References 375 6.1. Normative References 377 [CCITT.X680.2002] 378 International International Telephone and Telegraph 379 Consultative Committee, "Abstract Syntax Notation One 380 (ASN.1): Specification of basic notation", CCITT 381 Recommendation X.680, July 2002. 383 [CCITT.X690.2002] 384 International International Telephone and Telegraph 385 Consultative Committee, "ASN.1 encoding rules: 386 Specification of basic encoding Rules (BER), Canonical 387 encoding rules (CER) and Distinguished encoding rules 388 (DER)", CCITT Recommendation X.690, July 2002. 390 [I-D.ietf-pkix-rfc2560bis] 391 Santesson, S., Myers, M., Ankney, R., Malpani, A., 392 Galperin, S., and C. Adams, "X.509 Internet Public Key 393 Infrastructure Online Certificate Status Protocol - OCSP", 394 draft-ietf-pkix-rfc2560bis-17 (work in progress), April 395 2013. 397 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 398 Requirement Levels", BCP 14, RFC 2119, March 1997. 400 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 401 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 402 May 2008. 404 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 405 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 407 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 408 Housley, R., and W. Polk, "Internet X.509 Public Key 409 Infrastructure Certificate and Certificate Revocation List 410 (CRL) Profile", RFC 5280, May 2008. 412 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 413 Extension Definitions", RFC 6066, January 2011. 415 6.2. Informative References 417 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 418 Adams, "X.509 Internet Public Key Infrastructure Online 419 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 421 Author's Address 422 Yngve N. Pettersen 424 Email: yngve@spec-work.net