idnits 2.17.00 (12 Aug 2021) /tmp/idnits32918/draft-ietf-tls-multiple-cert-status-extension-05.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 (March 29, 2013) is 3339 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 320, but not defined ** 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: 4 errors (**), 0 flaws (~~), 3 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 March 29, 2013 4 Intended status: Standards Track 5 Expires: September 30, 2013 7 The TLS Multiple Certificate Status Request Extension 8 draft-ietf-tls-multiple-cert-status-extension-05 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 multiple certificate status methods. Also defined is a new method 15 based on the Online Certificate Status Protocol (OCSP) that servers 16 can use to provide status information not just about the server's own 17 certificate, but also the status of intermediate certificates in the 18 chain. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 30, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 1. Introduction 66 The Transport Layer Security (TLS) Extension [RFC6066] framework 67 defines, among other extensions, the Certificate Status Extension 68 (also referred to as "OCSP stapling") that clients can use to request 69 the server's copy of the current status of its certificate. The 70 benefits of this extension include a reduced number of roundtrips and 71 network delays for the client to verify the status of the server's 72 certificate and a reduced load on the certificate issuer's status 73 response servers, thus solving a problem that can become significant 74 when the issued certificate is presented by a frequently visited 75 server. 77 There are two problems with the existing Certificate Status 78 extension. First, it does not provide functionality to request the 79 status information about intermediate Certification Authority (CA) 80 certificates, which means the client has to request status 81 information through other methods, such as Certificate Revocation 82 Lists (CRLs), introducing further delays. Second, the current format 83 of the extension and requirements in the TLS protocol prevents a 84 client from offering the server multiple status methods. 86 Many CAs are now issuing intermediate CA certificates that not only 87 specify the publication point for their CRLs in a CRL Distribution 88 Point [RFC5280], but also specify a URL for their OCSP [RFC2560] 89 server in Authority Information Access [RFC5280]. Given that client- 90 cached CRLs are frequently out of date, clients would benefit from 91 using OCSP to access up-to-date status information about intermediate 92 CA certificates. The benefit to the issuing CA is less clear, as 93 providing the bandwidth for the OCSP responder can be costly, 94 especially for CAs with many high-traffic subscriber sites, and this 95 cost is a concern for many CAs. There are cases where OCSP requests 96 for a single high-traffic site caused significant network problems 97 for the issuing CA. 99 Clients will benefit from the TLS server providing certificate status 100 information regardless of type, not just for the server certificate, 101 but also for the intermediate CA certificates. Combining the status 102 checks into one extension will reduce the roundtrips needed to 103 complete the handshake by the client to just those needed for 104 negotiating the TLS connection. Also, for the Certification 105 Authorities, the load on their servers will depend on the number of 106 certificates they have issued, not on the number of visitors to those 107 sites. 109 For such a new system to be introduced seamlessly, clients need to be 110 able to indicate support for the existing OCSP Certificate Status 111 method, and a new multiple-OCSP mode. 113 Unfortunately, the definition of the Certificate Status extension 114 only allows a single Certificate Status extension to be defined in a 115 single extension record in the handshake, and the TLS Protocol 116 [RFC5246] only allows a single record in the extension list for any 117 given extension. This means that it is not possible for clients to 118 indicate support for new methods while still supporting older 119 methods, which would cause problems for interoperability between 120 newer clients and older servers. This will not just be an issue for 121 the multiple status request mode proposed above, but also for any 122 other future status methods that might be introduced. This will be 123 true not just for the current PKIX infrastructure [RFC5280], but also 124 for alternative PKI structures. 126 The solution to this problem is to define a new extension, 127 status_request_v2, with an extended format that allows the client to 128 indicate support for multiple status request methods. This is 129 implemented using a list of CertificateStatusRequestItemV2 records in 130 the extension record. As the server will select the single status 131 method based on the selected cipher suite and the certificate 132 presented, no significant changes are needed in the server's 133 extension format. 135 1.1. Requirements Language 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [RFC2119]. 141 1.2. Presentation language 143 This document defines protocol structures using the same conventions 144 and presentation language as defined in Section 4 of [RFC5246]. 146 2. Multiple Certificate Status Extension 148 2.1. New extension 150 The extension defined by this document is indicated by the 151 "status_request_v2" in the ExtensionType enum (originally defined by 152 [RFC6066]), which uses the following value: 154 enum { 155 status_request_v2(XX), (65535) 156 } ExtensionType; 158 [[ EDITOR: The value used for status_request_v2 has been left as 159 "XX". This value will be assigned when this draft progresses to 160 RFC.]] 162 2.2. Multiple Certificate Status Request record 164 Clients that support a certificate status protocol like OCSP may send 165 the status_request_v2 extension to the server in order to use the TLS 166 handshake to transfer such data instead of downloading it through 167 separate connections. When using this extension, the 168 "extension_data" field (defined by Section 7.4.1.4 in[RFC5246]) of 169 the extension SHALL contain a CertificateStatusRequestList where: 171 struct { 172 CertificateStatusType status_type; 173 uint16 request_length; /* Length of request field in bytes */ 174 select (status_type) { 175 case ocsp: OCSPStatusRequest; 176 case ocsp_multi: OCSPStatusRequest; 177 } request; 178 } CertificateStatusRequestItemV2; 180 enum { ocsp(1), ocsp_multi(2), (255) } CertificateStatusType; 181 struct { 182 ResponderID responder_id_list<0..2^16-1>; 183 Extensions request_extensions; 184 } OCSPStatusRequest; 186 opaque ResponderID<1..2^16-1>; 187 opaque Extensions<0..2^16-1>; 189 struct { 190 CertificateStatusRequestItemV2 certificate_status_req_list<1..2^16-1>; 191 } CertificateStatusRequestList; 193 In the OCSPStatusRequest (originally defined by [RFC6066]), the 194 "ResponderIDs" provides a list of OCSP responders that the client 195 trusts. A zero-length "responder_id_list" sequence has the special 196 meaning that the responders are implicitly known to the server, e.g., 197 by prior arrangement, or are identfied by the certificates used by 198 the server. "Extensions" is a DER encoding [CCITT.X690.2002] of the 199 OCSP request extensions. 201 Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as 202 defined in [RFC2560]. "Extensions" is imported from [RFC5280]. A 203 zero-length "request_extensions" value means that there are no 204 extensions (as opposed to a zero-length ASN.1 SEQUENCE, which is not 205 valid for the "Extensions" type). 207 In the case of the "id-pkix-ocsp-nonce" OCSP extension, [RFC2560] is 208 unclear about its encoding; for clarification, the nonce MUST be a 209 DER-encoded OCTET STRING, which is encapsulated as another OCTET 210 STRING (note that implementations based on an existing OCSP client 211 will need to be checked for conformance to this requirement). 213 The items in the list of CertificateStatusRequestItemV2 entries are 214 in order of the client's preference (favorite choice first). 216 A server that receives a client hello containing the 217 "status_request_v2" extension MAY return a suitable certificate 218 status response message to the client along with the server's 219 certificate message. If OCSP is requested, it SHOULD use the 220 information contained in the extension when selecting an OCSP 221 responder and SHOULD include request_extensions in the OCSP request. 223 The server returns a certificate status response along with its 224 certificate by sending a "CertificateStatus" message (originally 225 defined by [RFC6066]) immediately after the [RFC5246] (Section 7.4.2) 226 "Certificate" message (and before any "ServerKeyExchange" or 227 "CertificateRequest" messages). If a server returns a 228 "CertificateStatus" message in response to a status_request_v2 229 request, then the server MUST have included an extension of type 230 "status_request_v2" with empty "extension_data" in the extended 231 server hello. The "CertificateStatus" message is conveyed using the 232 handshake message type "certificate_status" as follows (see also 233 [RFC6066]): 235 struct { 236 CertificateStatusType status_type; 237 select (status_type) { 238 case ocsp: OCSPResponse; 239 case ocsp_multi: OCSPResponseList; 240 } response; 241 } CertificateStatus; 243 opaque OCSPResponse<0..2^24-1>; 245 struct { 246 OCSPResponse ocsp_response_list<1..2^24-1>; 247 } OCSPResponseList; 249 An "OCSPResponse" element (originally defined by [RFC6066]) contains 250 a complete, DER-encoded OCSP response (using the ASN.1 251 [CCITT.X680.2002] type OCSPResponse defined in [RFC2560]). Only one 252 OCSP response, with a length of at least one byte, may be sent for 253 status_type "ocsp". 255 An "ocsp_response_list" contains a list of "OCSPResponse" elements, 256 as specified above, each containing the OCSP response for the 257 matching corresponding certificate in the server's Certificate TLS 258 handshake message. That is, the first entry is the OCSP response for 259 the first certificate in the Certificate list, the second entry is 260 the response for the second certificate, and so on. The list MAY 261 contain fewer OCSP responses than there were certificates in the 262 Certificate handshake message, but there MUST NOT be more responses 263 than there were certificates in the list. Individual elements of the 264 list MAY have a length of 0 (zero) bytes, if the server does not have 265 the OCSP response for that particular certificate stored, in which 266 case, the client MUST act as if a response was not received for that 267 particular certificate. If the client receives a 268 "ocsp_response_list" that does not contain a response for one or more 269 of the certificates in the completed certificate chain, the client 270 SHOULD attempt to validate the certificate using an alternative 271 retrieval method, such as downloading the relevant CRL; OCSP SHOULD 272 in this situation only be used for the end entity certificate, not 273 intermediate CA certificates, for reasons stated above. 275 Note that a server MAY also choose not to send a "CertificateStatus" 276 message, even if it has received a "status_request_v2" extension in 277 the client hello message and has sent a "status_request_v2" extension 278 in the server hello message. Additionally, note that that a server 279 MUST NOT send the "CertificateStatus" message unless it received 280 either a "status_request" or "status_request_v2" extension in the 281 client hello message and sent a corresponding "status_request" or 282 "status_request_v2" extension in the server hello message. 284 Clients requesting an OCSP response and receiving one or more OCSP 285 responses in a "CertificateStatus" message MUST check the OCSP 286 response(s) and abort the handshake if the response is a revoked 287 status or other unacceptable responses (as determined by client 288 policy), with a bad_certificate_status_response(113) alert. This 289 alert is always fatal. 291 If the response is inconclusive, then the client MAY decide to allow 292 the connection if it believes it will have the opportunity to check 293 the validity of the certificate through another means, e.g., by 294 directly querying the issuer's CRL or OCSP responders. The client 295 MUST abort the connection if it needs to engage in activities that 296 require trust in the server, and the server certificate has not been 297 sufficiently validated. An example of where the client might wish to 298 continue is with EAP-TLS, where the client can use another mechanism 299 to check the status of a certificate once it obtains network access. 300 In this case, the client could continue with the handshake, but it 301 would be inappropriate for the client to disclose a username and 302 password until it has fully validated the server certificate. 304 3. IANA Considerations 306 Section 2.1 defines the new TLS Extension status_request_v2 enum, 307 which should be added to the ExtensionType Values list in the IANA 308 Transport Layer Security (TLS) Extensions registry. 310 Section 2.2 describes a TLS CertificateStatusType Registry to be 311 maintained by the IANA. The new registry is called TLS Certificate 312 Status Types and should be defined under the Transport Layer Security 313 (TLS) Extensions registry. CertificateStatusType values are to be 314 assigned via IETF Review as defined in [RFC5226]. The initial 315 registry corresponds to the definition of "ExtensionType" in 316 Section 2.2. 318 Value Description Reference 319 1 ocsp [This RFC] 320 2 ocsp_multi [This RFC] 322 4. Security Considerations 324 General Security Considerations for TLS Extensions are covered in 325 [RFC5246]. Security Considerations for the particular extension 326 specified in this document are given below. In general, implementers 327 should continue to monitor the state of the art and address any 328 weaknesses identified. 330 4.1. Security Considerations for status_request_v2 332 If a client requests an OCSP response, it must take into account that 333 an attacker's server using a compromised key could (and probably 334 would) pretend not to support the extension. In this case, a client 335 that requires OCSP validation of certificates SHOULD either contact 336 the OCSP server directly or abort the handshake. 338 Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may 339 improve security against attacks that attempt to replay OCSP 340 responses; see Section 4.4.1 of [RFC2560] for further details. 342 The security considerations of [RFC2560] apply to OCSP requests and 343 responses. 345 5. Acknowledgements 347 This document is based on [RFC6066] authored by Donald Eastlake 3rd. 349 6. Normative References 351 [CCITT.X680.2002] 352 International International Telephone and Telegraph 353 Consultative Committee, "Abstract Syntax Notation One 354 (ASN.1): Specification of basic notation", CCITT 355 Recommendation X.680, July 2002. 357 [CCITT.X690.2002] 358 International International Telephone and Telegraph 359 Consultative Committee, "ASN.1 encoding rules: 360 Specification of basic encoding Rules (BER), Canonical 361 encoding rules (CER) and Distinguished encoding rules 362 (DER)", CCITT Recommendation X.690, July 2002. 364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 365 Requirement Levels", BCP 14, RFC 2119, March 1997. 367 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 368 Adams, "X.509 Internet Public Key Infrastructure Online 369 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 371 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 372 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 373 May 2008. 375 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 376 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 378 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 379 Housley, R., and W. Polk, "Internet X.509 Public Key 380 Infrastructure Certificate and Certificate Revocation List 381 (CRL) Profile", RFC 5280, May 2008. 383 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 384 Extension Definitions", RFC 6066, January 2011. 386 Author's Address 388 Yngve N. Pettersen 390 Email: yngve@spec-work.net