idnits 2.17.1 draft-ietf-tls-multiple-cert-status-extension-00.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 (May 9, 2012) is 4364 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 May 9, 2012 5 Expires: November 10, 2012 7 The TLS Multiple Certificate Status Request Extension 8 draft-ietf-tls-multiple-cert-status-extension-00 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 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on November 10, 2012. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 1. Introduction 72 The Transport Layer Security (TLS) Extension [RFC6066] framework 73 defines, among other extensions, the Certificate Status Extension 74 that clients can use to request the server's copy of the current 75 status of its certificate. The benefits of this extension include a 76 reduced number of roundtrips and network delays for the client to 77 verify the status of the server's certificate and a reduced load on 78 the certificate issuer's status response servers, thus solving a 79 problem that can become significant when the issued certificate is 80 presented by a frequently visited server. 82 There are two problems with the existing Certificate Status 83 extension. First, it does not provide functionality to request the 84 status information about intermediate Certification Authority (CA) 85 certificates, which means the client has to request status 86 information through other methods, such as CRLs, thus adding 87 additional delay. Second, the current format of the extension and 88 requirements in the TLS protocol prevents a client from offering the 89 server multiple status methods. 91 Many Certification Authorities are now issuing intermediate CA 92 certificates that not only specify a CRL Distribution Point 93 [RFC5280], but also a URL for OCSP [RFC2560] Certificate Status 94 requests. Given that client-cached CRLs are frequently out of date, 95 using OCSP to access up-to-date status information about intermediate 96 CA certificates will be of great benefit to clients. The benefit to 97 the issuing CA is less clear, as providing the bandwidth for the OCSP 98 responder can be costly, especially for CAs with many high-traffic 99 subscriber sites, and this cost is a concern for many CAs. There are 100 cases where OCSP requests for a single high-traffic site caused 101 significant network problems for the issuing CA. 103 For these reasons, it will be beneficial to use the TLS server to 104 provide the certificate status information not just for the server 105 certificate, but also for the intermediate CA certificates. This 106 will reduce the roundtrips needed to complete the handshake by the 107 client to just those needed for negotiating the TLS connection. 108 Also, for the Certification Authorities, the load on their servers 109 will depend on the number of certificates they have issued, not on 110 the number of visitors to those sites. 112 For such a new system to be introduced seamlessly, it must be 113 possible for clients to indicate support for the existing OCSP 114 Certificate Status 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 only 119 allows a single record in the extension list for any given extension. 120 This means that it is not possible for clients to indicate support 121 for new methods while still supporting older methods, which would 122 cause problems for interoperability between newer clients and older 123 servers. This will not just be an issue for the multiple status 124 request mode proposed above, but also for any other future status 125 methods that might be introduced. This will be true not just for the 126 current PKIX infrastructure, but also 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 by using a list of CertificateStatusRequestItem records 132 in 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 2. Multiple Certificate Status Extension 138 2.1. New extension 140 The extension defined by this document is indicated by the 141 "status_request_v2" in the ExtensionType enum, which uses the 142 following value: 144 enum { 145 status_request_v2(XX) (65535) 146 } ExtensionType; 148 [[ EDITOR: The value used for status_request_v2 has been left as XX. 149 This value will be assigned when this draft progresses to RFC.]] 151 2.2. Multiple Certificate Status Request record 153 Clients that support a certificate status protocol like OCSP may send 154 the status_request_v2 extension to the server in order to use the TLS 155 handshake to transfer such data instead of downloading it through 156 separate connections. When using this extension, the 157 "extension_data" field of the extension SHALL contain a 158 CertificateStatusRequestList where: 160 struct { 161 CertificateStatusType status_type; 162 uint16 request_length; /* Length of request field in bytes */ 163 select (status_type) { 164 case ocsp: OCSPStatusRequest; 165 case ocsp_multi: OCSPStatusRequest; 166 } request; 167 } CertificateStatusRequestItem; 169 enum { ocsp(1), ocsp_multi(YY), (255) } CertificateStatusType; 171 struct { 172 ResponderID responder_id_list<0..2^16-1>; 173 Extensions request_extensions; 174 } OCSPStatusRequest; 176 opaque ResponderID<1..2^16-1>; 177 opaque Extensions<0..2^16-1>; 179 struct { 180 CertificateStatusRequestItem certificate_status_req_list<1..2^16-1> 181 } CertificateStatusRequestList 183 [[ EDITOR: The value used for ocsp_multi has been left as YY. This 184 value will be assigned when this draft progresses to RFC.]] 185 In the OCSPStatusRequestItem, the "ResponderIDs" provides a list of 186 OCSP responders that the client trusts. A zero-length 187 "responder_id_list" sequence has the special meaning that the 188 responders are implicitly known to the server, e.g., by prior 189 arrangement, or are identfied by the certificates used by the server. 190 "Extensions" is a DER encoding of OCSP request extensions. 192 Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as 193 defined in [RFC2560]. "Extensions" is imported from [RFC5280]. A 194 zero-length "request_extensions" value means that there are no 195 extensions (as opposed to a zero-length ASN.1 SEQUENCE, which is not 196 valid for the "Extensions" type). 198 In the case of the "id-pkix-ocsp-nonce" OCSP extension, [RFC2560] is 199 unclear about its encoding; for clarification, the nonce MUST be a 200 DER-encoded OCTET STRING, which is encapsulated as another OCTET 201 STRING (note that implementations based on an existing OCSP client 202 will need to be checked for conformance to this requirement). 204 The list of CertificateStatusRequestItem entries MUST be in order of 205 preference. 207 A server that receive a client hello containing the 208 "status_request_v2" extension MAY return a suitable certificate 209 status response message to the client along with the server's 210 certificate message. If OCSP is requested, it SHOULD use the 211 information contained in the extension when selecting an OCSP 212 responder and SHOULD include request_extensions in the OCSP request. 214 The server returns a certificate status response along with its 215 certificate by sending a "CertificateStatus" message immediately 216 after the "Certificate" message (and before any "ServerKeyExchange" 217 or "CertificateRequest" messages). If a server returns a 218 "CertificateStatus" message in response to a status_request_v2 219 request, then the server MUST have included an extension of type 220 "status_request_v2" with empty "extension_data" in the extended 221 server hello. The "CertificateStatus" message is conveyed using the 222 handshake message type "certificate_status" as follows (see also 223 [RFC6066]): 225 struct { 226 CertificateStatusType status_type; 227 select (status_type) { 228 case ocsp: OCSPResponse; 229 case ocsp_multi: OCSPResponseList; 230 } response; 231 } CertificateStatus; 233 opaque OCSPResponse<0..2^24-1>; 235 struct { 236 OCSPResponse ocsp_response_list<1..2^24-1> 237 } OCSPResponseList 239 An "OCSPResponse" element contains a complete, DER-encoded 240 [CCITT.X680.2002] OCSP response (using the ASN.1 [CCITT.X680.2002] 241 type OCSPResponse defined in [RFC2560]). Only one OCSP response, 242 with a length of at least one byte, may be sent for status_type 243 "ocsp". 245 An "ocsp_response_list" contains a list of "OCSPResponse" elements, 246 as specified above, each containing the OCSP response for the 247 matching corresponding certificate in the server's Certificate TLS 248 handshake message. That is, the first entry is the OCSP response for 249 the first certificate in the Certificate list, the second entry is 250 the response for the second certificate, and so on. The list MAY 251 contain fewer OCSP responses than there were certificates in the 252 Certificate handshake message, but there MUST NOT be more responses 253 than there were certificates in the list. Individual elements of the 254 list MAY have a length of 0 (zero) bytes, if the server does not have 255 the OCSP response for that particular certificate stored, in which 256 case, the client MUST act as if a response was not received for that 257 particular certificate. If the client receives a 258 "ocsp_response_list" that does not contain a response for one or more 259 of the certificates in the completed certificate chain, the client 260 SHOULD attempt to validate the certificate using an alternative 261 retrieval method, such as downloading the relevant CRL; OCSP SHOULD 262 in this situation only be used for the end entity certificate, not 263 intermediate CA certificates, for reasons stated above. 265 Note that a server MAY also choose not to send a "CertificateStatus" 266 message, even if it has received a "status_request_v2" extension in 267 the client hello message and has sent a "status_request_v2" extension 268 in the server hello message. Additionally, note that that a server 269 MUST NOT send the "CertificateStatus" message unless it received 270 either a "status_request" or "status_request_v2" extension in the 271 client hello message and sent a corresponding "status_request" or 272 "status_request_v2" extension in the server hello message. 274 Clients requesting an OCSP response and receiving one or more OCSP 275 responses in a "CertificateStatus" message MUST check the OCSP 276 response(s) and abort the handshake, if the response is a revoked 277 status or is otherwise not satisfactory with a 278 bad_certificate_status_response(113) alert. This alert is always 279 fatal. 281 [[Open issue: At least one reviewer has suggested that the client 282 should treat an unsatisfactory (non-revoked) response as an empty 283 response for that particular response and fall back to the 284 alternative method described above]] 286 3. IANA Considerations 288 Section 2.1 defines the new TLS Extension status_request_v2 enum, 289 which should be added to the ExtensionType Values list in the IANA 290 TLS category after IETF Concensus has decided to add the value. 292 Section 2.2 describes a TLS CertificateStatusType Registry to be 293 maintained by the IANA. CertificateStatusType values are to be 294 assigned via IETF Review as defined in [RFC5226]. The initial 295 registry corresponds to the definition of "ExtensionType" in 296 Section 2.2. 298 4. Security Considerations 300 General Security Considerations for TLS Extensions are covered in 301 [RFC5246]. Security Considerations for the particular extension 302 specified in this document are given below. In general, implementers 303 should continue to monitor the state of the art and address any 304 weaknesses identified. 306 4.1. Security Considerations for status_request_v2 308 If a client requests an OCSP response, it must take into account that 309 an attacker's server using a compromised key could (and probably 310 would) pretend not to support the extension. In this case, a client 311 that requires OCSP validation of certificates SHOULD either contact 312 the OCSP server directly or abort the handshake. 314 Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may 315 improve security against attacks that attempt to replay OCSP 316 responses; see Section 4.4.1 of [RFC2560] for further details. 318 5. Acknowledgements 320 This document is based on [RFC6066] authored by Donald Eastlake 3rd. 322 6. Normative References 324 [CCITT.X680.2002] 325 International International Telephone and Telegraph 326 Consultative Committee, "Abstract Syntax Notation One 327 (ASN.1): Specification of basic notation", 328 CCITT Recommendation X.680, July 2002. 330 [CCITT.X690.2002] 331 International International Telephone and Telegraph 332 Consultative Committee, "ASN.1 encoding rules: 333 Specification of basic encoding Rules (BER), Canonical 334 encoding rules (CER) and Distinguished encoding rules 335 (DER)", CCITT Recommendation X.690, July 2002. 337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 338 Requirement Levels", BCP 14, RFC 2119, March 1997. 340 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 341 Adams, "X.509 Internet Public Key Infrastructure Online 342 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 344 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 345 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 346 May 2008. 348 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 349 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 351 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 352 Housley, R., and W. Polk, "Internet X.509 Public Key 353 Infrastructure Certificate and Certificate Revocation List 354 (CRL) Profile", RFC 5280, May 2008. 356 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 357 Extension Definitions", RFC 6066, January 2011. 359 Author's Address 361 Yngve N. Pettersen 362 Opera Software ASA 364 Email: yngve@opera.com