idnits 2.17.1 draft-hallambaker-revocation-options-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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 7, 2011) is 4761 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'C-Legacy-Browser' is mentioned on line 258, but not defined == Missing Reference: 'C-Legacy-Server' is mentioned on line 268, but not defined == Missing Reference: 'C-Legacy-DNS' is mentioned on line 148, but not defined == Missing Reference: 'R-Fraud' is mentioned on line 225, but not defined == Missing Reference: 'R-Comp' is mentioned on line 206, but not defined == Missing Reference: 'M-Client-Efficiency' is mentioned on line 210, but not defined == Missing Reference: 'M-Server-Admin' is mentioned on line 270, but not defined == Missing Reference: 'P-CAA' is mentioned on line 224, but not defined == Missing Reference: 'P-Short' is mentioned on line 262, but not defined == Missing Reference: 'P-Short-Optimized' is mentioned on line 241, but not defined == Missing Reference: 'P-Stapling-Flag' is mentioned on line 252, but not defined == Missing Reference: 'P-OCSP-LOCAL' is mentioned on line 265, but not defined == Missing Reference: 'P-OCSP-LOCAL-2ND' is mentioned on line 265, but not defined == Missing Reference: 'TBS' is mentioned on line 274, but not defined == Outdated reference: A later version (-04) exists of draft-hallambaker-donotissue-03 Summary: 1 error (**), 0 flaws (~~), 16 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Hallam-Baker 3 Internet-Draft Comodo Group Inc. 4 Intended status: Experimental April 7, 2011 5 Expires: October 9, 2011 7 Options for Improving PKIX Revocation 8 draft-hallambaker-revocation-options-00 10 Abstract 12 In recent weeks a number of proposals have been made for improving 13 the effectiveness of certificate revocation. This document is an 14 attempt to bring these proposals atogether and analyze them with 15 respect to a use cases and requirements framework. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on October 9, 2011. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 53 1.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.1. [C-Legacy-Browser] . . . . . . . . . . . . . . . . . . . . 4 57 3.2. [C-Legacy-Server] . . . . . . . . . . . . . . . . . . . . . 4 58 3.3. [C-Legacy-DNS] . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.1. [R-Fraud] . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.2. [R-Comp] . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 5.1. [M-Client-Efficiency] . . . . . . . . . . . . . . . . . . . 5 64 5.2. [M-Server-Admin] . . . . . . . . . . . . . . . . . . . . . 5 65 6. Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 6.1. [P-CAA] . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 6.2. [P-Short] . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 6.2.1. [P-Short]+[P-CAA] . . . . . . . . . . . . . . . . . . . 6 69 6.2.2. [P-Short-Optimized] . . . . . . . . . . . . . . . . . . 6 70 6.3. [P-Stapling-Flag] . . . . . . . . . . . . . . . . . . . . . 6 71 6.4. [P-OCSP-LOCAL][P-OCSP-LOCAL-2ND] . . . . . . . . . . . . . 7 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 75 10. Normative References . . . . . . . . . . . . . . . . . . . . . 7 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Definitions 80 1.1. Requirements Language 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119 [RFC2119]. 86 1.2. Defined Terms 88 The following terms are used in this document: 90 Certificate An X.509 Certificate, as specified in RFC 5280 91 [RFC5280]. 93 Certification Policy (CP) Specifies the criteria that a 94 Certification Authority undertakes to meet in its issue of 95 certificates. 97 Certification Practices Statement (CPS) Specifies the means by which 98 the criteria of the Certification Policy are met. In most cases 99 this will be the document against which the operations of the 100 Certification Authority are audited. 102 Certification Authority (CA) An entity that issues Certificates in 103 accordance with a specified Certification Policy. 105 Domain The set of resources associated with a DNS Domain Name. 107 Domain Name A DNS Domain name as specified in RFC 1035 [RFC1035] and 108 revisions. 110 Domain Name System (DNS) The Internet naming system specified in RFC 111 1035 [RFC1035] and revisions. 113 DNS Security (DNSSEC) Extensions to the DNS that provide 114 authentication services as specified in RFC 4033 [RFC4033] and 115 revisions. 117 Key A cryptographic key. 119 Public Key Infrastructure X.509 (PKIX) Standards and specifications 120 issued by the IETF that apply the X.509 [X.509] certificate 121 standards specified by the ITU to Internet applications as 122 specified in RFC 5280 [RFC5280] and related documents. 124 Resource Record (RR) A set of attributes bound to a Domain Name. 126 Relying Party A party that makes use of an application whose 127 operation depends on use of a Certificate or Key for making a 128 security decision. 130 Relying Application An application whose operation depends on use of 131 a Certificate or Key for making a security decision. 133 2. Use Cases 135 TBS 137 3. Constraints 139 3.1. [C-Legacy-Browser] 141 The legacy base of browsers does not support hard fail when an OCSP 142 responder is unavailable 144 3.2. [C-Legacy-Server] 146 The legacy base of servers does not support OCSP stapling 148 3.3. [C-Legacy-DNS] 150 The legacy DNS does not provide for cryptographic authentication of 151 responses 153 4. Requirements 155 4.1. [R-Fraud] 157 Prevent clients relying on mis-issued or fraudulently issued 158 certificates 160 4.2. [R-Comp] 162 Prevent clients relying on certificates that were legitimately issued 163 but have since been compromised (e.g. subject key is compromised) 165 5. Metrics 166 5.1. [M-Client-Efficiency] 168 Time spent checking certificate status in the browser 170 5.2. [M-Server-Admin] 172 Complexity of server operations. 174 6. Proposals 176 6.1. [P-CAA] 178 Certificate Authority Authorization [I-D.hallambaker-donotissue] 179 provides a general purpose, extensible platform that allows domain 180 name owners to express certificate issue requirements. Although 181 currently limited to specification of trust roots, it is extensible 182 to allow additional properties to be agreed and specified. While the 183 security of CAA is improved with deployment of DNSSEC in the 184 specified zone, CAA is still an effective control without DNSSEC. 186 Deployment of CAA does not require code at the client or server, 187 except that the DNS server used must be recent enough to support 188 specification of unknown RRs. It is thus compatible with [C-Legacy- 189 Browser] and [C-Legacy-Server]. 191 6.2. [P-Short] 193 Certificate is issued for short lifetime (24-72 hours). Servers must 194 thus ensure that they continuously update their certificate stores to 195 download and install certificates as they are issued. 197 One critical issue in this approach is the synchronization of the 198 relying party clock to that of the issuing CA (presumed to be within 199 a few seconds of UTC). In order to avoid unnecessary rejection of 200 certificates it is probably desirable for a server to only start 201 using a certificate 24 hours after the notValidBefore time and to 202 renew the certificate 24 hours before the notValidAfter time is 203 reached. Experts are currently looking into the detailed 204 implications of timing and short lived certificates. 206 By itself, [P-Short] meets criteria [R-Comp] but not [R-Fraud] since 207 an attacker can simply request issue of a long lived certificate from 208 a compromised CA. 210 [P-Short] is netural with respect to [M-Client-Efficiency] and 211 requires a significant change to server administration and is thus 212 negative for [M-Server-Admin] in the short term. In the long term 213 however, it is much easier to guarantee the reliability of a 214 certificate download that must happen every day and is thus 215 automated, than a procedure that happens once a year and is likely to 216 be forgotten. 218 Deployment of [P-Short] is fully compatible with the legacy base of 219 deployed browsers which will all accept short lifetime certificates 220 and refuse to rely on a certificate that has expired. 222 6.2.1. [P-Short]+[P-CAA] 224 Use of [P-Short] in combination with an appropriate flag in [P-CAA] 225 allows the requirement [R-Fraud] to be met, provided that either the 226 CA or the client software checks the CAA record. 228 This proposal is identical with respect to the metrics and 229 constraints as [P-Short] 231 6.2.2. [P-Short-Optimized] 233 If the lifetime of a short lived certificate is shorter than the 234 validity period accepted for an OCSP or CRL response, a client MAY 235 choose to rely on the short lived certificate without performing the 236 customary revocation checking. A PKIX certificate extension MAY be 237 specified as a means of enabling a client to determine that a 238 certificate is intended for use as a short-lived certificate without 239 revocation checking. 241 [P-Short-Optimized] allows an improvement in the metric [M-Client- 242 Efficiency] by eliminating the need for separate revocation checking. 244 6.3. [P-Stapling-Flag] 246 A certificate includes a flag that tells relying parties that it is 247 only to be used with TLS implementations that support OCSP stapling. 248 Should a client attempt to connect to the server that does not offer 249 the stapled OCSP response, the connection is invalid and must be 250 aborted. 252 [P-Stapling-Flag] arguably requires less administration effort than 253 [P-Short] as it allows the site to continue to use long lived 254 certificates and is thus better on [M-Server-Admin]. The principal 255 disadvantage being that it requires deployment of a server that can 256 support stapling and is thus worse on [C-Legacy-Server]. The 257 stapling flag will only be observed by new clients and the proposal 258 thus fails to meet [C-Legacy-Browser]. 260 6.4. [P-OCSP-LOCAL][P-OCSP-LOCAL-2ND] 262 Another proposal similar to [P-Short] is for the subject to host 263 their own OCSP responder which is in theory less likely to be 264 vulnerable to failure. This may be the primary OCSP responder 265 [P-OCSP-LOCAL] or merely a secondary [P-OCSP-LOCAL-2ND]. 267 While this approach does not require server support for OCSP stapling 268 and is thus compatible with [C-Legacy-Server], the administrative 269 effort for the subject is considerably greater and it thus fails on 270 [M-Server-Admin]. 272 7. Security Considerations 274 [TBS] 276 8. IANA Considerations 278 None 280 9. Acknowledgements 282 This draft draws on input from many contributors, in some cases the 283 same proposal being made more than once in different contexts. The 284 concept of short lived certificates was proposed in WAP forum. This 285 proposal and the proposal to use local OCSP was mentioned on a 286 Mozilla telecon. 288 10. Normative References 290 [I-D.hallambaker-donotissue] 291 Hallam-Baker, P., Stradling, R., and B. Laurie, "DNS 292 Certification Authority Authorization (CAA) Resource 293 Record", draft-hallambaker-donotissue-03 (work in 294 progress), March 2011. 296 [RFC1035] Mockapetris, P., "Domain names - implementation and 297 specification", STD 13, RFC 1035, November 1987. 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, March 1997. 302 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 303 Rose, "DNS Security Introduction and Requirements", 304 RFC 4033, March 2005. 306 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 307 Housley, R., and W. Polk, "Internet X.509 Public Key 308 Infrastructure Certificate and Certificate Revocation List 309 (CRL) Profile", RFC 5280, May 2008. 311 [X.509] International Telecommunication Union, "ITU-T 312 Recommendation X.509 (11/2008): Information technology - 313 Open systems interconnection - The Directory: Public-key 314 and attribute certificate frameworks", ITU-T 315 Recommendation X.509, November 2008. 317 Author's Address 319 Phillip Hallam-Baker 320 Comodo Group Inc. 322 Email: philliph@comodo.com