idnits 2.17.1 draft-hallambaker-ocspdigest-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 : ---------------------------------------------------------------------------- ** 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 (October 19, 2012) is 4179 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1035' is defined on line 369, but no explicit reference was found in the text == Unused Reference: 'RFC4366' is defined on line 375, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) Summary: 2 errors (**), 0 flaws (~~), 3 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: Standards Track R. Stradling 5 Expires: April 22, 2013 Comodo CA Ltd. 6 October 19, 2012 8 OCSP Digest Extension 9 draft-hallambaker-ocspdigest-01 11 Abstract 13 The OCSP digest extension creates a strong cryptographic binding 14 between an OCSP token and the certificate it asserts a status value 15 for. Support for the digest identifier extension permits a 16 certificate issuer to employ a high assurance cryptographic digest 17 function such as SHA2 to attest to the authenticity of their 18 certificates in a fashion that is fully downwards compatible with 19 legacy clients that only support SHA1. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 22, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 57 2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Digest Agility . . . . . . . . . . . . . . . . . . . . . . 3 59 2.2. Transparency Requirement . . . . . . . . . . . . . . . . . 4 60 2.3. The Current OCSP Protocol . . . . . . . . . . . . . . . . . 5 61 3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.1. OCSP Request . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.2. OCSP Response . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.2.1. Transparency requirement . . . . . . . . . . . . . . . 7 65 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 67 5.1. Disclosing non existence of certificates . . . . . . . . . 8 68 5.2. Client disclosure of certificate digest identifier . . . . 8 69 5.3. Client detection of service compromise . . . . . . . . . . 8 70 5.4. Verifying service compliance . . . . . . . . . . . . . . . 8 71 6. For discussion. . . . . . . . . . . . . . . . . . . . . . . . . 8 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 73 8. Normative References . . . . . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Definitions 78 1.1. Requirements Language 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC 2119 [RFC2119]. 84 2. Purpose 86 The OCSP digest identifier is provides a mechanism that permits a new 87 cryptographic digest function to be used to authenticate an X.509v3 88 certificate in a manner that is fully backwards compatible with 89 deployed browsers. This capability overcomes a 'deployment deadlock' 90 condition that would otherwise make deployment of new cryptographic 91 digest algorithms unacceptable to many certifcate users. 93 A second advantage of the OCSP digest identifier is to provide an 94 affirmative demonstration that the OCSP responder had actual 95 knowledge of the existence of the certificate whose status is being 96 queried. This provides a transparency control on the operation of 97 the Certificate Authority issuing the certificate. A Certificate 98 Authority that has lost track of which certificates have been 99 legitimately issued will be unable to determine if a response MUST or 100 MUST NOT contain the digest identifier extension. 102 2.1. Digest Agility 104 Although the SSL Certificate industry has successfully completed a 105 transition from use of the MD5 digest algorithm to SHA-1, this 106 transition was a straightforward one as every Web browser that 107 supported MD5 also provided support for SHA-1. Recent cryptanalytic 108 work on the SHA-1 algorithm strongly suggest that while the use of 109 SHA-1 in TLS should not be an immediate cause for concern it is 110 prudent to ensure that there is a viable transition plan to use of 111 SHA-2, preferably a plan that can be put into effect at short notice. 113 Although the X.509v3 certificate format has supported use of SHA-2 as 114 a cryptographic digest since the algorithm was first published in 115 2001, there is currently no viable transition plan that permits SHA-2 116 to be deployed in a manner that will be acceptable to most operators 117 of Web sites that use the certificates. 119 Merely adding support for a new cryptographic algorithm does little 120 to improve the security of a system against attack. In general a 121 reduction in risk will only be realized by withdrawing the old 122 algorithm from use. 124 The TLS protocol and X.509v3 certificates are widely used to ensure 125 the accountability, authenticity and confidentiality of Web 126 transactions. One consequence of this widespead use is that the 127 population of Web browsers has become highly hetrogeneous. While 128 many Web users only use the latest Web browsers with the most up to 129 date security features, a significant proportion of Web users do not. 130 In particular there remains a significant number of Web users whose 131 browsers are ten or more years old. 133 The use of older Web browsers has significant consequences for 134 merchants using the Web to offer products and/or services. A 135 merchant whose Web site is not accessible to 5% of the population of 136 Web browsers risks losing 5% of their sales. Although most Web 137 merchants are interested in offering their customers 'security', 138 their motivation for doing so is to encourage them to do business 139 with them. Thus a security feature that causes the merchant to lose 140 more customers than it gains will be unacceptable to them. 142 Certificate Authorities will not issue certificates for which there 143 is no market and browser providers cannot insist on the use of a 144 credential format that no sites want and no Certificate Authority 145 will issue. Deployment of SHA-2 has thus reached a deadlock 146 condition in which none of the parties involved can or will act until 147 all the other parties have acted first. 149 Although most Certificate issuers have the technical capability to 150 offer digital certificates that use the SHA-2 algorithm, there is 151 currently no demand for such certificates except for use in closed 152 environments where the legacy browser constraints do not apply. 154 The OCSP digest identifier extension permits an OCSP response to 155 identify the certificate whose status it reports using a 156 cryptographic digest of the certificate. This provides a stronger 157 binding between that OCSP token and the certificate to which it 158 applies than the current protocol permits. 160 In a typical deployment scenario, the certificate itself would be 161 signed using a SHA-1 digest to ensure backwards compatibility with 162 legacy browsers and the OCSP token would contain a digest identifier 163 extension that uses the SHA-2 algorithm or better. This approach 165 2.2. Transparency Requirement 167 A transparency requirement is a constraint on the operation of a 168 service that may be verified by through access to public information 169 alone. 171 A transparency requirement is thus a stronger criteria than an audit 172 requirement that may require privileged access to verify. 174 The digest identifier extension MAY be used to enforce a transparency 175 requirement that an OCSP responder mantain a complete and accurate 176 log of all certificates issued and accurately reports the existence 177 status of the certificate(s) for which OCSP requests are made. 179 Such a transparency requirement would typically be placed on an OCSP 180 service that is operated by a Certification Authority to provide 181 transparency with respect to compliance with a breach notification 182 requirement. 184 2.3. The Current OCSP Protocol 186 The OCSP protocol defines an online service that reports the status 187 of an issued X.509v3 certificate. The original protocol permitted an 188 OCSP response to specify the certificate it reported status of by 189 means of a CertID structure specified as follows: 191 CertID ::= SEQUENCE { 192 hashAlgorithm AlgorithmIdentifier, 193 issuerNameHash OCTET STRING, -- Hash of Issuer's DN 194 issuerKeyHash OCTET STRING, -- Hash of Issuers public key 195 serialNumber CertificateSerialNumber } 197 While the issuerNameHash and serialNumber should be unique, this is a 198 matter of convention rather than a cryptographic guarantee, a 199 convention that an attacker might be able to subvert in the case that 200 a CA was breached. 202 The original justification made for only supporting a weak binding to 203 the certificate in the CertID structure was that it should be 204 possible to operate an OCSP service from information contained in 205 CRLs alone 207 This particular requirement is rejected. A protocol specification 208 should not attempt to enforce a lowest common denominator for 209 security. Services that have additional information available should 210 not be unable to deliver it to clients merely because other services 211 might not have that information. 213 It is certainly legitimate for a relying party making use of an OCSP 214 responder to consider a service that reports the status 'good' for a 215 certificate that has never been issued to be defective. An 216 accomodation made in a specification to permit a certain level of 217 service to be offered by constrained services should not prevent 218 other services that are not limited from offering a greater degree of 219 security. 221 In this case a purpose of the specification is precisely to determine 222 whether the OCSP responder has actual knowledge of the certificates 223 issued. 225 3. Syntax 227 The digest identifier extension MAY be used in CRLs or OCSP requests 228 and responses. The extension has the following format: 230 cabf-ocsp-digest OBJECT IDENTIFIER ::= { cabf 2 } 232 DigestData ::= SEQUENCE { 233 hashAlgorithm AlgorithmIdentifier, 234 CertHash OCTET STRING} 236 The CertHash contains the digest value of the certificate to which 237 the enclosing status assertion or request applies. 239 3.1. OCSP Request 241 When specified in an OCSP request as a singleRequestExtensions entry, 242 the Digest Identifier extension provides an additional means of 243 identifying the certificate whose status is being queried rather than 244 a replacement for the existing CertID structure. 246 Should an OCSP responder detect an inconsistency between the contents 247 of the CertID structure and the Digest Identifier extension, there 248 are three possible explanations: 250 o The discrepancy is due to an unintentional software error in 251 either the client software or the CA infrastructure 253 o The discrepancy is due to an OCSP request being intentionally 254 misformed. 256 o The digest algorithm that was originally used to sign the digital 257 certificate has been compromised and the OCSP request was made by 258 client software that recieved a compromised certificate. 260 An OCSP responder that is able to do so SHOULD take approrpiate steps 261 to determine the cause of such discrepancies. 263 3.2. OCSP Response 265 When specified in an OCSP request as a singleExtensions entry, the 266 Digest Identifier extension provides an additional means of 267 identifying the certificate whose status is being reported. 269 If the contents of either the CertID or the Digest Identifier 270 extension are inconsistent with the certificate being querried, the 271 response entry SHOULD be rejected as not matching the specified 272 certificate. 274 If no matching response entries are present in a response, a client 275 SHOULD consider the status of the certificate to be unknown. 277 3.2.1. Transparency requirement 279 An OCSP responder MUST NOT present a digest identifier extension as a 280 singleExtensions entry unless it has actual knowledge that the 281 corresponding certificate exists. 283 An external policy MAY verify compliance with the transparency 284 requirement by generating a sequence of queries for certificates that 285 are known to exist and dummy queries for certificates that are known 286 not to exist. 288 to pass the transparency requirement, an OCSP responder MUST return 289 the appropriate response to each type of query: 291 o If the certificate exists: A response with a digest identifier 292 extension. 294 o Otherwise: A response that indicates an invalid status for the 295 certificate and does not contain a digest identifier extension. 297 Note that it is possible for a third party to determine compliance 298 with the transparency requirement on a statistical basis even if the 299 OCSP request discloses the digest identifier of the corresponding 300 certificate in some way. 302 4. Acknowledgements 304 [List of CABForum and PKIX contributors] 306 5. Security Considerations 307 5.1. Disclosing non existence of certificates 309 The deployed OCSP infrastructure only permits a client to determine 310 that a certificate has not been revoked. Some OCSP responders return 311 the OCSP status 'good' in cases where the status of the certificate 312 is not known. Some OCSP clients have identical behavior in the case 313 that the returned status is 'good' and 'unknown'. 315 Consistent use of the digest identifier permits a client to 316 distinguish these cases. 318 5.2. Client disclosure of certificate digest identifier 320 A client may disclose the digest identifier of an issued certificate 321 in an OCSP request, thus providing the service with the information 322 necessary to form a response in the case that it is not entitled to 323 do so by reason of not having actual knowledge of the existence of 324 the certificate. 326 5.3. Client detection of service compromise 328 Steps that a client should take in the event that a service 329 compromise is detected are outside the scope of this document. 331 5.4. Verifying service compliance 333 A third party may verify the compliance of an OCSP service with the 334 transparency requirement by following the process specified in 335 section Section 3.2.1. 337 6. For discussion. 339 [RFC EDITOR: DELETE PRIOR TO PUBLICATION] 341 Does the OCSP Request use make any sense at all? It does provide the 342 starting point for an early detection system for bad crypto but that 343 is all. Also it is quite possible that TLS OCSP stapling will render 344 the need for the request moot by the time a digest breach occurs. 346 If the request extension use was removed it would mean that the 347 responder was providing an effective proof that the status source had 348 specific knowledge of the certificate whose status was being queried. 349 (This proof would be further strengthened by use of a MAC) 351 Such proof would be relevant in determining if a responder had actual 352 knowledge of the certificates it reported the status of. If a query 353 is made for a certificate that is known does not or should not exist, 354 the responder should respond with a generic 'unknown' error response. 355 If the responder attempts to return a digest value in such cases, the 356 responses are clearly spurious. 358 This scheme could be further strengthened by adding an extension OID 359 to the certificate to specify that the OCSP responder will always 360 return the digest identifier extension. This enables a relying 361 application to reject any non conformant responses as spurious. 363 7. IANA Considerations 365 No action by IANA is required. 367 8. Normative References 369 [RFC1035] Mockapetris, P., "Domain names - implementation and 370 specification", STD 13, RFC 1035, November 1987. 372 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 373 Requirement Levels", BCP 14, RFC 2119, March 1997. 375 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 376 and T. Wright, "Transport Layer Security (TLS) 377 Extensions", RFC 4366, April 2006. 379 [X.509] International Telecommunication Union, "ITU-T 380 Recommendation X.509 (11/2008): Information technology - 381 Open systems interconnection - The Directory: Public-key 382 and attribute certificate frameworks", ITU-T 383 Recommendation X.509, November 2008. 385 [X.680] International Telecommunication Union, "ITU-T 386 Recommendation X.680 (11/2008): Information technology - 387 Abstract Syntax Notation One (ASN.1): Specification of 388 basic notation", ITU-T Recommendation X.680, 389 November 2008. 391 Authors' Addresses 393 Phillip Hallam-Baker 394 Comodo Group Inc. 396 Email: philliph@comodo.com 397 Rob Stradling 398 Comodo CA Ltd. 400 Email: rob.stradling@comodo.com