idnits 2.17.1 draft-ietf-tls-multiple-cert-status-extension-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 : ---------------------------------------------------------------------------- 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 (July 8, 2012) is 4281 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 July 8, 2012 5 Expires: January 9, 2013 7 The TLS Multiple Certificate Status Request Extension 8 draft-ietf-tls-multiple-cert-status-extension-01 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 that a server can use to provide status information (i.e., based on 16 the Online Certificate Status Protocol and Server-Based Certificate 17 Validation Protocol) not just about the server's own certificate, but 18 also the status of intermediate certificates in the 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 January 9, 2013. 37 Copyright Notice 39 Copyright (c) 2012 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 that clients can use to request the server's copy of the current 69 status of its certificate. The benefits of this extension include a 70 reduced number of roundtrips and network delays for the client to 71 verify the status of the server's certificate and a reduced load on 72 the certificate issuer's status response servers, thus solving a 73 problem that can become significant when the issued certificate is 74 presented by a frequently visited server. 76 There are two problems with the existing Certificate Status 77 extension. First, it does not provide functionality to request the 78 status information about intermediate Certification Authority (CA) 79 certificates, which means the client has to request status 80 information through other methods, such as Certificate Revocation 81 Lists (CRLs), thus adding additional delay. Second, the current 82 format of the extension and requirements in the TLS protocol prevents 83 a client from offering the server multiple status methods; there are 84 two methods available, the Online Certificate Status Protocol (OCSP) 85 [RFC2560] and the Server-Based Certificate Validation Protocol (SCVP) 86 [RFC5055]. 88 Many CAs now issue intermediate CA certificates that not only specify 89 the publication point for their CRLs in CRL Distribution Point 90 [RFC5280], but also specify a URL for their OCSP [RFC2560] server in 91 Authority Information Access [RFC5280]. Given that client-cached 92 CRLs are frequently out of date, clients would benefit from using 93 OCSP, or other protocols, to access up-to-date status information 94 about intermediate CA certificates. The benefit to the issuing CA is 95 less clear, as providing the bandwidth for the OCSP responder can be 96 costly, especially for CAs with many high-traffic subscriber sites, 97 and this cost is a concern for many CAs. There are cases where OCSP 98 requests for a single high-traffic site caused significant network 99 problems for the issuing CA. 101 Clients will benefit from the TLS server providing certificate status 102 information regardless of type, not just for the server certificate, 103 but also for the intermediate CA certificates. Combining the status 104 checks into one extension will reduce the roundtrips needed to 105 complete the handshake by the client to just those needed for 106 negotiating the TLS connection. Also, for the Certification 107 Authorities, the load on their servers will depend on the number of 108 certificates they have issued, not on the number of visitors to those 109 sites. 111 For such a new system to be introduced seamlessly, clients need to be 112 able to indicate support for the existing OCSP Certificate Status 113 method and a new multiple-OCSP mode or the new SCVP mode. 115 Unfortunately, the definition of the Certificate Status extension 116 only allows a single Certificate Status extension to be defined in a 117 single extension record in the handshake, and the TLS Protocol 118 [RFC5246] only allows a single record in the extension list for any 119 given extension. This means that it is not possible for clients to 120 indicate support for new methods while still supporting older 121 methods, which would cause problems for interoperability between 122 newer clients and older servers. This will not just be an issue for 123 the multiple status request mode proposed above, but also for any 124 other future status methods that might be introduced. This will be 125 true not just for the current PKIX infrastructure [RFC5280], but also 126 for alternative PKI structures. 128 The solution to this problem is to define a new extension, 129 status_request_v2, with an extended format that allows the client to 130 indicate support for multiple status request methods. This is 131 implemented using a list of CertificateStatusRequestItem records in 132 the extension record. As the server will select the single status 133 method based on the selected cipher suite and the certificate 134 presented, no significant changes are needed in the server's 135 extension format. 137 1.1. Requirements Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in RFC 2119 [RFC2119]. 143 2. Multiple Certificate Status Extension 145 2.1. New extension 147 The extension defined by this document is indicated by the 148 "status_request_v2" in the ExtensionType enum, which uses the 149 following value: 151 enum { 152 status_request_v2(XX), (65535) 153 } ExtensionType; 155 [[ EDITOR: The value used for status_request_v2 has been left as 156 "XX". This value will be assigned when this draft progresses to 157 RFC.]] 159 2.2. Multiple Certificate Status Request record 161 Clients that support a certificate status protocol (i.e., OCSP and 162 SCVP) may send the status_request_v2 extension to the server in order 163 to use the TLS handshake to transfer such data instead of downloading 164 it through separate connections. When using this extension, the 165 "extension_data" field of the extension SHALL contain a 166 CertificateStatusRequestList where: 168 struct { 169 CertificateStatusType status_type; 170 uint16 request_length; /* Length of request field in bytes */ 171 select (status_type) { 172 case ocsp: OCSPStatusRequest; 173 case ocsp_multi: OCSPStatusRequest; 174 case scvp: SCVPStatusRequest; 175 } request; 176 } CertificateStatusRequestItem; 178 enum { 179 ocsp(1), ocsp_multi(YY), scvp (AA),(255) 180 } CertificateStatusType; 182 struct { 183 ResponderID responder_id_list<0..2^16-1>; 184 Extensions request_extensions; 185 } OCSPStatusRequest; 187 struct { 188 ResponderID responder_id_list<0..2^16-1>; 189 Extensions request_extensions; 190 } SCVPStatusRequest; 192 opaque ResponderID<1..2^16-1>; 193 opaque Extensions<0..2^16-1>; 195 struct { 196 CertificateStatusRequestItem certificate_status_req_list<1..2^16-1> 197 } CertificateStatusRequestList 199 [[ EDITOR: The values used for ocsp_multi and scvp have been left as 200 "YY" and "AA", respectively. These values will be assigned when this 201 draft progresses to RFC.]] 203 In the OCSPStatusRequest and SCVPStatusRequest structures, the 204 "ResponderIDs" provide a list of OCSP and SCVP responders 205 (respectively) that the client trusts. A zero-length 206 "responder_id_list" sequence has the special meaning that the 207 responders are implicitly known to the server, e.g., by prior 208 arrangement, or are identfied by the certificates used by the server. 209 "Extensions" is a DER encoding [CCITT.X690.2002] of the OCSP and SCVP 210 request extensions (respectively). 212 Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as 213 defined in [RFC2560] (for OCSP) and [RFC5055] (for SCVP). 214 "Extensions" is imported from [RFC5280]. A zero-length 215 "request_extensions" value means that there are no extensions (as 216 opposed to a zero-length ASN.1 SEQUENCE, which is not valid for the 217 "Extensions" type). 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). 225 The list of CertificateStatusRequestItem entries MUST be in order of 226 preference. 228 A server that receive a client hello containing the 229 "status_request_v2" extension MAY return a suitable certificate 230 status response message to the client along with the server's 231 certificate message. If OCSP is requested, it SHOULD use the 232 information contained in the extension when selecting an OCSP 233 responder and SHOULD include request_extensions in the OCSP request. 235 The server returns a certificate status response along with its 236 certificate by sending a "CertificateStatus" message immediately 237 after the "Certificate" message (and before any "ServerKeyExchange" 238 or "CertificateRequest" messages). If a server returns a 239 "CertificateStatus" message in response to a status_request_v2 240 request, then the server MUST have included an extension of type 241 "status_request_v2" with empty "extension_data" in the extended 242 server hello. The "CertificateStatus" message is conveyed using the 243 handshake message type "certificate_status" as follows (see also 244 [RFC6066]): 246 struct { 247 CertificateStatusType status_type; 248 select (status_type) { 249 case ocsp: OCSPResponse; 250 case ocsp_multi: OCSPResponseList; 251 case scvp: SCVPResponse; 252 } response; 253 } CertificateStatus; 255 opaque OCSPResponse<0..2^24-1>; 257 opaque SCVPResponse<0..2^24-1>; 259 struct { 260 OCSPResponse ocsp_response_list<1..2^24-1> 261 } OCSPResponseList 263 An "OCSPResponse" element contains a complete, DER-encoded OCSP 264 response (using the ASN.1 syntax [CCITT.X680.2002] of type 265 OCSPResponse as defined in [RFC2560]). Only one OCSP response, with 266 a length of at least one byte, may be sent for status_type "ocsp". 268 An "SCVPResponse" element contains a complete, DER-encoded SCVP 269 response (using the ASN.1 syntax [CCITT.X680.2002] of type CVResponse 270 as defined in [RFC5055]). Only one SCVP response, with a length of 271 at least one byte, may be sent for status_type "scvp". An SCVP 272 response can include the status of intermediate certificates. 274 An "ocsp_response_list" contains a list of "OCSPResponse" elements, 275 as specified above, each containing the OCSP response for the 276 matching corresponding certificate in the server's Certificate TLS 277 handshake message. That is, the first entry is the OCSP response for 278 the first certificate in the Certificate list, the second entry is 279 the response for the second certificate, and so on. The list MAY 280 contain fewer OCSP responses than there were certificates in the 281 Certificate handshake message, but there MUST NOT be more responses 282 than there were certificates in the list. Individual elements of the 283 list MAY have a length of 0 (zero) bytes, if the server does not have 284 the OCSP response for that particular certificate stored, in which 285 case, the client MUST act as if a response was not received for that 286 particular certificate. If the client receives a 287 "ocsp_response_list" that does not contain a response for one or more 288 of the certificates in the completed certificate chain, the client 289 SHOULD attempt to validate the certificate using an alternative 290 retrieval method, such as downloading the relevant CRL; OCSP SHOULD 291 in this situation only be used for the end entity certificate, not 292 intermediate CA certificates, for reasons stated above. 294 Note that a server MAY also choose not to send a "CertificateStatus" 295 message, even if it has received a "status_request_v2" extension in 296 the client hello message and has sent a "status_request_v2" extension 297 in the server hello message. Additionally, note that that a server 298 MUST NOT send the "CertificateStatus" message unless it received 299 either a "status_request" or "status_request_v2" extension in the 300 client hello message and sent a corresponding "status_request" or 301 "status_request_v2" extension in the server hello message. 303 Clients requesting a certificate response and receiving either one or 304 more OCSP responses or a SCVP response in a "CertificateStatus" 305 message MUST check the response(s) and abort the handshake, if the 306 response is a revoked status or is otherwise not satisfactory with a 307 bad_certificate_status_response(113) alert. This alert is always 308 fatal. 310 [[Open issue: At least one reviewer has suggested that the client 311 should treat an unsatisfactory (non-revoked) response as an empty 312 response for that particular response and fall back to the 313 alternative method described above]] 315 3. IANA Considerations 317 Section 2.1 defines the new TLS Extension status_request_v2 enum, 318 which should be added to the ExtensionType Values list in the IANA 319 TLS category after IETF Concensus has decided to add the value. 321 Section 2.2 describes a TLS CertificateStatusType Registry to be 322 maintained by the IANA. CertificateStatusType values are to be 323 assigned via IETF Review as defined in [RFC5226]. The initial 324 registry corresponds to the definition of "ExtensionType" in 325 Section 2.2. 327 4. Security Considerations 329 General Security Considerations for TLS Extensions are covered in 330 [RFC5246]. Security Considerations for the particular extension 331 specified in this document are given below. In general, implementers 332 should continue to monitor the state of the art and address any 333 weaknesses identified. 335 4.1. Security Considerations for status_request_v2 337 If a client requests an OCSP or SCVP response, it must take into 338 account that an attacker's server using a compromised key could (and 339 probably would) pretend not to support the extension. In this case, 340 a client that requires OCSP or SCVP validation of certificates SHOULD 341 either contact the OCSP or SCVP server directly or abort the 342 handshake. 344 Use of the OCSP (id-pkix-ocsp-nonce) or SCVP nonce request extension 345 may improve security against attacks that attempt to replay OCSP or 346 SCVP responses; see Section 4.4.1 of [RFC2560] and Section 9 of 347 [RFC5055] for further details. 349 The security considerations of [RFC2560] apply to OCSP requests and 350 responses, and the security considerations of [RFC5055] apply to SCVP 351 erquests and responses. 353 5. Acknowledgements 355 This document is based on [RFC6066] authored by Donald Eastlake 3rd. 357 The SCVP status type description is based on text provided by Sean 358 Turner. 360 6. Normative References 362 [CCITT.X680.2002] 363 International International Telephone and Telegraph 364 Consultative Committee, "Abstract Syntax Notation One 365 (ASN.1): Specification of basic notation", 366 CCITT Recommendation X.680, July 2002. 368 [CCITT.X690.2002] 369 International International Telephone and Telegraph 370 Consultative Committee, "ASN.1 encoding rules: 371 Specification of basic encoding Rules (BER), Canonical 372 encoding rules (CER) and Distinguished encoding rules 373 (DER)", CCITT Recommendation X.690, July 2002. 375 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 376 Requirement Levels", BCP 14, RFC 2119, March 1997. 378 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 379 Adams, "X.509 Internet Public Key Infrastructure Online 380 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 382 [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. 383 Polk, "Server-Based Certificate Validation Protocol 384 (SCVP)", RFC 5055, December 2007. 386 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 387 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 388 May 2008. 390 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 391 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 393 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 394 Housley, R., and W. Polk, "Internet X.509 Public Key 395 Infrastructure Certificate and Certificate Revocation List 396 (CRL) Profile", RFC 5280, May 2008. 398 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 399 Extension Definitions", RFC 6066, January 2011. 401 Author's Address 403 Yngve N. Pettersen 404 Opera Software ASA 406 Email: yngve@opera.com