idnits 2.17.1 draft-pettersen-tls-ext-multiple-ocsp-03.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 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 (March 6, 2012) is 4406 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) ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Pettersen 3 Internet-Draft Opera Software ASA 4 Intended status: Standards Track March 6, 2012 5 Expires: September 7, 2012 7 Adding Multiple TLS Certificate Status Extension requests 8 draft-pettersen-tls-ext-multiple-ocsp-03 10 Abstract 12 This document introduces a replacement of the TLS Certificate Status 13 Extension to allow clients to specify and support multiple 14 certificate status methods. Also being introduced is a new OCSP- 15 based method that servers can use to provide status information not 16 just about the server's own certificate, but also the status of 17 intermediate certificates in the chain. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 7, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 1. Introduction 71 The Transport Layer Security Extension [RFC6066] framework defines, 72 among other extensions, the Certificate Status Extension that clients 73 can use to request the server's copy of the current status of its 74 certificate. The benefits of this extension include a reduced number 75 of roundtrips and network delays for the client to verify the status 76 of the server's certificate using other retrieval methods and a 77 reduced load on the certificate issuer's status response servers, 78 thus solving a problem that can become significant when the issued 79 certificate is presented by a frequently visited server. 81 There are two problems with the existing Certificate Status extension 82 as it is currently defined. First, it does not provide functionality 83 to request the status information about intermediate CA certificates, 84 which means the client has to request this through other retrieval 85 methods, such as CRLs, which can cause significant delays when the 86 revocation list has to be refreshed. Second, the current format of 87 the extension and requirements in the TLS protocol prevents a client 88 from offering the server multiple status methods. 90 Many Certificate Authorities are now issuing intermediate CA 91 certificates that not only specify a CRL Distribution Point[RFC5280], 92 but also a URL for OCSP [RFC2560] Certificate Status requests. Given 93 that CRLs, particularly those cached by the client, are frequently 94 less up to date than is possible for an OCSP responder, using OCSP to 95 access up-to-date status information about intermediate CA 96 certificates will be of great benefit to clients. The benefit to the 97 issuing CA is less clear, as providing the bandwidth for the OCSP 98 responder can be costly, especially for CAs with many subscriber 99 sites. The author is aware that the cost of providing this bandwidth 100 just for site certificates has been a concern to some CAs, 101 particularly the smaller ones, and it follows naturally that doubling 102 or tripling this cost could be problematic for the CAs. The author 103 is also aware of at least one case when OCSP requests for a single 104 high-traffic site caused significant network problems for the issuing 105 CA. 107 For these reasons, it will be beneficial to use the TLS server to 108 provide the certificate status information not just for the server 109 certificate, but also for the intermediate CA certificates. This 110 will reduce the roundtrips needed to complete the handshake by the 111 client to just those needed for negotiating the TLS connection. 112 Also, for the Certificate Authorities, the load on their servers will 113 depend on the number of certificates they have issued, not on the 114 number of visitors to those sites. 116 For such a new system to be introduced seamlessly, it must be 117 possible for clients to indicate support for the existing OCSP 118 Certificate Status method, and a new multiple, OCSP mode. 120 Unfortunately, the definition of the Certificate Status extension 121 only allows a single Certificate Status extension to be defined in a 122 single extension record in the handshake, and the TLS Protocol only 123 allows a single record in the extension list for any given extension. 124 This means that it is not possible for clients to indicate support 125 for new methods while still supporting older methods, which would 126 cause problems for interoperability between newer clients and older 127 servers. This will not just be an issue for the multiple status 128 request mode proposed above, but also for any other future status 129 methods that might be introduced. This will be true not just for the 130 current PKIX infrastructure, but also for alternative PKI structures. 132 The solution to this problem is to define a new extension, 133 status_request_v2, with an extended format that allows the client to 134 indicate support for multiple status request methods. This is 135 implemented by using a list of CertificateStatusRequestItem records 136 in the extension record. As the server will select the single status 137 method based on the selected cipher suite and the certificate 138 presented, no significant changes are needed in the server's 139 extension format. 141 2. Multiple Certificate Status Extension 143 2.1. New extension 145 The extension added by this document is indicated by the 146 "status_request_v2" in the ExtensionType enum, which is updated with 147 this value: 149 enum { 150 status_request_v2(XX) (65535) 151 } ExtensionType; 153 [[ EDITOR: The value used for status_request_v2 has been left as XX. 154 This value will be assigned when this draft progresses to RFC.]] 156 2.2. Multiple Certificate Status Request record 158 Clients that support a certificate status protocol like OCSP may send 159 the status_request_v2 extension to the server in order to use the TLS 160 handshake to transfer such data instead of downloading it through 161 separate connections. When using this extension, the 162 "extension_data" field of the extension SHALL contain a 163 CertificateStatusRequestList where: 165 struct { 166 CertificateStatusType status_type; 167 uint16 request_length; /* Length of request field in bytes */ 168 select (status_type) { 169 case ocsp: OCSPStatusRequest; 170 case ocsp_multi: OCSPStatusRequest; 171 } request; 172 } CertificateStatusRequestItem; 174 enum { ocsp(1), ocsp_multi(YY), (255) } CertificateStatusType; 176 struct { 177 ResponderID responder_id_list<0..2^16-1>; 178 Extensions request_extensions; 179 } OCSPStatusRequest; 181 opaque ResponderID<1..2^16-1>; 182 opaque Extensions<0..2^16-1>; 184 struct { 185 CertificateStatusRequestItem certificate_status_req_list<1..2^16-1> 186 } CertificateStatusRequestList 188 [[ EDITOR: The value used for ocsp_multi has been left as YY. This 189 value will be assigned when this draft progresses to RFC.]] 191 In the OCSPStatusRequestItem, the "ResponderIDs" provides a list of 192 OCSP responders that the client trusts. A zero-length 193 "responder_id_list" sequence has the special meaning that the 194 responders are implicitly known to the server, e.g., by prior 195 arrangement, or are identfied by the certificates used by the server. 196 "Extensions" is a DER encoding of OCSP request extensions. 198 Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as 199 defined in [RFC2560]. "Extensions" is imported from [RFC5280]. A 200 zero-length "request_extensions" value means that there are no 201 extensions (as opposed to a zero-length ASN.1 SEQUENCE, which is not 202 valid for the "Extensions" type). 204 In the case of the "id-pkix-ocsp-nonce" OCSP extension, [RFC2560] is 205 unclear about its encoding; for clarification, the nonce MUST be a 206 DER-encoded OCTET STRING, which is encapsulated as another OCTET 207 STRING (note that implementations based on an existing OCSP client 208 will need to be checked for conformance to this requirement). 210 The list of CertificateStatusRequestItem entries MUST be in order of 211 preference. 213 Servers that receive a client hello containing the "status_request" 214 extension MAY return a suitable certificate status response to the 215 client along with their certificate. If OCSP is requested, they 216 SHOULD use the information contained in the extension when selecting 217 an OCSP responder and SHOULD include request_extensions in the OCSP 218 request. 220 Servers return a certificate status response along with their 221 certificate by sending a "CertificateStatus" message immediately 222 after the "Certificate" message (and before any "ServerKeyExchange" 223 or "CertificateRequest" messages). If a server returns a 224 "CertificateStatus" message in response to a status_request_v2 225 request, then the server MUST have included an extension of type 226 "status_request_v2" with empty "extension_data" in the extended 227 server hello. The "CertificateStatus" message is conveyed using the 228 handshake message type "certificate_status" as follows (see also 229 [RFC6066]): 231 struct { 232 CertificateStatusType status_type; 233 select (status_type) { 234 case ocsp: OCSPResponse; 235 case ocsp_multi: OCSPResponseList; 236 } response; 237 } CertificateStatus; 239 opaque OCSPResponse<0..2^24-1>; 241 struct { 242 OCSPResponse ocsp_response_list<1..2^24-1> 243 } OCSPResponseList 245 An "OCSPResponse" element contains a complete, DER-encoded OCSP 246 response (using the ASN.1 type OCSPResponse defined in [RFC2560]) . 247 Only one OCSP response, with a length of at least one byte, may be 248 sent for status_type "ocsp". 250 An "ocsp_response_list" contains a list of "OCSPResponse" elements, 251 as specified above, each containing the OCSP response for the 252 matching corresponding certificate in the server's Certificate TLS 253 handshake message. that is, the first entry is the OCSP response for 254 the first certificate in the Certificate list, the second entry is 255 the response for the second certificate, and so on. The list MAY 256 contain fewer OCSP responses than there were certificates in the 257 Certificate handshake message, but there MUST NOT be more responses 258 than there were certificates in the list. Individual elements of the 259 list MAY have a length of 0 (zero) bytes, if the server does not have 260 the OCSP response for that particular certificate stored, in which 261 case, the client MUST act as if a response was not received for that 262 particular certificate. If the client receives a 263 "ocsp_response_list" that does not contain a response for one or more 264 of the certificates in the completed certificate chain, the client 265 SHOULD attempt to validate the certificate using an alternative 266 retrieval method, such as downloading the relevant CRL; OCSP SHOULD 267 in this situation only be used for the end entity certificate, not 268 intermediate CA certificates, for reasons stated above. 270 Note that a server MAY also choose not to send a "CertificateStatus" 271 message, even if it has received a "status_request_v2" extension in 272 the client hello message and has sent a "status_request_v2" extension 273 in the server hello message. Additionally, note that that a server 274 MUST NOT send the "CertificateStatus" message unless it received 275 either a "status_request" or "status_request_v2" extension in the 276 client hello message and sent a corresponding "status_request" or 277 "status_request_v2" extension in the server hello message. 279 Clients requesting an OCSP response and receiving one or more OCSP 280 responses in a "CertificateStatus" message MUST check the OCSP 281 response(s) and abort the handshake, if the response is a revoked 282 status or is otherwise not satisfactory with a 283 bad_certificate_status_response(113) alert. This alert is always 284 fatal. 286 [[Open issue: At least one reviewer has suggested that the client 287 should treat an unsatisfactory (non-revoked) response as an empty 288 response for that particular response and fall back to the 289 alternative method described above]] 291 3. IANA Considerations 293 Section 2.1 defines the new TLS Extension status_request_v2 enum, 294 which should be added to the ExtensionType Values list in the IANA 295 TLS category after IETF Concensus has decided to add the value. 297 Section 2.2 describes a TLS CertificateStatusType Registry to be 298 maintained by the IANA. CertificateStatusType values are to be 299 assigned via IETF Review as defined in [RFC5226]. The initial 300 registry corresponds to the definition of "ExtensionType" in 301 Section 2.2. 303 4. Security Considerations 305 General Security Considerations for TLS Extensions are covered in 306 [RFC5246]. Security Considerations for the particular extension 307 specified in this document are given below. In general, implementers 308 should continue to monitor the state of the art and address any 309 weaknesses identified. 311 4.1. Security Considerations for status_request_v2 313 If a client requests an OCSP response, it must take into account that 314 an attacker's server using a compromised key could (and probably 315 would) pretend not to support the extension. In this case, a client 316 that requires OCSP validation of certificates SHOULD either contact 317 the OCSP server directly or abort the handshake. 319 Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may 320 improve security against attacks that attempt to replay OCSP 321 responses; see Section 4.4.1 of [RFC2560] for further details. 323 5. Alternative methods for similar functionality 325 There may be alternative methods to accomplish the same objective as 326 this proposal, but without defining a new TLS Extension. 328 One possible method is that each OCSP response includes, recursively 329 or separately, the OCSP response for its own signer as a 330 responseExtensions. The problem with this method is that either the 331 responder has to send this to all requestors, leading to increased 332 bandwidth usage, or a special request extension or URL have to be 333 sent by the TLS server requesting the OCSP response, and it would 334 also lead to unnecessary bandwidth usage for the TLS server, if the 335 connecting client cannot use the extra OCSP responses. It is the 336 author's opinion that this approach would require the same level of 337 complexity as the proposed extension in the webservers, in order to 338 reduce bandwidth consumption, at least while phasing in the 339 technology, and the OCSP responders would require similar level of 340 complexity to produce the variant responses. 342 6. Acknowledgements 344 This document is based on [RFC6066] authored by Donald Eastlake 3rd. 346 7. Normative References 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, March 1997. 351 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 352 Adams, "X.509 Internet Public Key Infrastructure Online 353 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 355 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 356 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 357 May 2008. 359 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 360 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 362 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 363 Housley, R., and W. Polk, "Internet X.509 Public Key 364 Infrastructure Certificate and Certificate Revocation List 365 (CRL) Profile", RFC 5280, May 2008. 367 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 368 Extension Definitions", RFC 6066, January 2011. 370 Author's Address 372 Yngve N. Pettersen 373 Opera Software ASA 375 Email: yngve@opera.com