idnits 2.17.1 draft-ietf-pkix-ocspagility-11.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 abstract seems to contain references ([RFC2560]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC2560, but the abstract doesn't seem to directly say this. It does mention RFC2560 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2560, updated by this document, for RFC5378 checks: 1997-10-23) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2, 2011) is 4709 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) ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) ** Downref: Normative reference to an Informational RFC: RFC 5912 -- Obsolete informational reference (is this intentional?): RFC 3280 (ref. 'RFC2459') (Obsoleted by RFC 5280) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Santesson 3 Internet-Draft 3xA Security 4 Intended status: Proposed Standard P. Hallam-Baker 5 Updates: 2560 (once approved) Default Deny Security 6 Expires: December 4, 2011 June 2, 2011 8 Online Certificate Status Protocol Algorithm Agility 9 draft-ietf-pkix-ocspagility-11 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright and License Notice 34 Copyright (c) 2011 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Abstract 49 The Online Certificate Status Protocol (OSCP) [RFC2560] requires 50 server responses to be signed but does not specify a mechanism for 51 selecting the signature algorithm to be used. This may lead to 52 avoidable interoperability failures in contexts where multiple 53 signature algorithms are in use. This document specifies rules for 54 server signature algorithm selection and an extension that allows a 55 client to advise a server that specific signature algorithms are 56 supported. 58 Table of Contents 60 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1 Requirements Language . . . . . . . . . . . . . . . . . . . 3 62 2 OCSP Algorithm Agility Requirements . . . . . . . . . . . . . . 3 63 3 Updates to Mandatory and Optional Cryptographic Algorithms . . 4 64 4 Client Indication of Preferred Signature Algorithms . . . . . . 5 65 5 Responder Signature Algorithm Selection . . . . . . . . . . . . 6 66 5.1 Dynamic Response . . . . . . . . . . . . . . . . . . . . . 6 67 5.2 Static Response . . . . . . . . . . . . . . . . . . . . . . 6 68 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 69 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 70 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 71 8.1 Use of insecure algorithms . . . . . . . . . . . . . . . . 7 72 8.2 Man in the Middle Downgrade Attack . . . . . . . . . . . . 8 73 8.3. Denial of Service Attack . . . . . . . . . . . . . . . . . 8 74 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 9.1 Normative References . . . . . . . . . . . . . . . . . . . 9 76 9.2 Informative References . . . . . . . . . . . . . . . . . . 9 77 Appendix A - ASN.1 Modules . . . . . . . . . . . . . . . . . . . . 10 78 A.1 ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . 10 79 A.2 1988 ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 11 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 1 Introduction 84 The Online Certificate Status Protocol (OCSP) [RFC2560] defines a 85 protocol for obtaining certificate status information from an online 86 service. An OCSP responder may or may not be issued an OCSP responder 87 certificate by the certification authority (CA) that issued the 88 certificate whose status is being queried. An OCSP responder may 89 provide pre-signed OCSP responses or may sign responses when queried. 91 RFC 2560 [RFC2560] specifies a means for an OCSP responder to 92 indicate the signature and digest algorithms used in a response but 93 not how those algorithms are specified. The only algorithm 94 requirements established by that protocol specification are that the 95 OCSP client SHALL support the DSA algorithm sig-alg-oid specified in 96 section 7.2.2 of [RFC2459] and SHOULD be capable of processing RSA 97 signatures as specified in section 7.2.1 of [RFC2459]. The only 98 requirement placed on responders by RFC 2560 is that they SHALL 99 support the SHA1 hashing algorithm. 101 This document specifies rules for server signature algorithm 102 selection and an extension that allows a client to advise a server 103 that specific signature algorithms are supported. 105 1.1 Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 2 OCSP Algorithm Agility Requirements 113 Since algorithms other than the mandatory to implement algorithms are 114 Allowed, and since a client currently has no mechanism to indicate 115 it's algorithm preferences, there is always a risk that a server 116 choosing a non-mandatory algorithm, will generate a response that the 117 client may not support. 119 While an OCSP responder may apply rules for algorithm selection, 120 e.g., using the signature algorithm employed by the CA for signing 121 CRLs and certificates, such rules may fail in common situations: 123 o The algorithm used to sign the CRLs and certificates may not be 124 consistent with key pair being used by the OCSP responder to sign 125 responses. 127 o A request for an unknown certificate provides no basis for a 128 responder to select from among multiple algorithm options. 130 The last criterion cannot be resolved through the information 131 available from in-band signaling using the RFC 2560 [RFC2560] 132 protocol, without modifying the protocol. 134 In addition, an OCSP responder may wish to employ different signature 135 algorithms than the one used by the CA to sign certificates and CRLs 136 for several reasons: 138 o The responder may employ an algorithm for certificate status 139 response that is less computationally demanding than for signing 140 the certificate itself. 142 o An implementation may wish to guard against the possibility of a 143 compromise resulting from a signature algorithm compromise by 144 employing two separate signature algorithms. 146 This document describes: 148 o A mechanism that allows a client to indicate the set of preferred 149 signature algorithms. 151 o Rules for signature algorithm selection that maximizes the 152 probability of successful operation in the case that no supported 153 preferred algorithm(s) are specified. 155 3 Updates to Mandatory and Optional Cryptographic Algorithms 157 Section 4.3 "Mandatory and Optional Cryptographic Algorithms" of RFC 158 2560 [RFC2560] is updated as follows: 160 OLD: Clients that request OCSP services SHALL be capable of 161 processing responses signed used DSA keys identified by the DSA 162 sig-alg-oid specified in section 7.2.2 of [RFC2459]. Clients 163 SHOULD also be capable of processing RSA signatures as specified 164 in section 7.2.1 of [RFC2459]. OCSP responders SHALL support the 165 SHA1 hashing algorithm. 167 NEW: Clients that request OCSP services SHALL be capable of 168 processing responses signed using RSA with SHA-1 (identified by 169 sha1WithRSAEncryption OID specified in [RFC3279]) and RSA with 170 SHA-256 (identified by sha256WithRSAEncryption OID specified in 171 [RFC4055]). Clients SHOULD also be capable of processing 172 responses signed using DSA keys (identified by the id-dsa-with- 173 sha1 OID specified in [RFC3279]). Clients MAY support other 174 algorithms. 176 4 Client Indication of Preferred Signature Algorithms 178 A client MAY declare a preferred set of algorithms in a request by 179 including a preferred signature algorithms extension in 180 requestExtensions of the OCSPRequest [RFC2560]. 182 id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 } 184 PreferredSignatureAlgorithms ::= SEQUENCE OF 185 PreferredSignatureAlgorithm 187 PreferredSignatureAlgorithm ::= SEQUENCE { 188 sigIdentifier AlgorithmIdentifier, 189 pubKeyAlgIdentifier SMIMECapability OPTIONAL 190 } 192 The syntax of AlgorithmIdentifier is defined in section 4.1.1.2 of 193 RFC 5280 [RFC5280] The syntax of SMIMECapability is defined in RFC 194 5751 [RFC5751] 196 sigIdentifier specifies the signature algorithm the client prefers, 197 e.g. algorithm=ecdsa-with-sha256. Parameters are absent for most 198 common signature algorithms. 200 pubKeyAlgIdentifier specifies the subject public key algorithm 201 identifier the client prefers in the server's certificate used to 202 validate the OCSP response. e.g. algorithm=id-ecPublicKey and 203 parameters= secp256r1. 205 pubKeyAlgIdentifier is OPTIONAL and provides means to specify 206 parameters necessary to distinguish among different usages of a 207 particular algorithm, e.g. it may be used by the client to specify 208 what curve it supports for a given elliptic curve algorithm. 210 The client MUST support each of the specified preferred signature 211 algorithms and the client MUST specify the algorithms in the order of 212 preference, from the most preferred to the least preferred. 214 Section 5 of this document describes how a server selects an 215 algorithm for signing OCSP responses to the requesting client. 217 5 Responder Signature Algorithm Selection 219 RFC 2560 [RFC2560] does not specify a mechanism for deciding the 220 signature algorithm to be used in an OCSP response. As previously 221 noted this does not provide a sufficient degree of certainty as to 222 the algorithm selected to facilitate interoperability. 224 5.1 Dynamic Response 226 A responder MAY maximize the potential for ensuring interoperability 227 by selecting a supported signature algorithm using the following 228 order of precedence, as long as the selected algorithm meets all 229 security requirements of the OCSP responder, where the first method 230 has the highest precedence: 232 1. Select an algorithm specified as a preferred signing algorithm in 233 the client request 235 2. Select the signing algorithm used to sign a certificate 236 revocation list (CRL) issued by the certificate issuer providing 237 status information for the certificate specified by CertID 239 3. Select the signing algorithm used to sign the OCSPRequest 241 4. Select a signature algorithm that has been advertised as being 242 the default signature algorithm for the signing service using an 243 out of band mechanism 245 5. Select a mandatory or recommended signing algorithm specified for 246 the version of the OCSP protocol in use 248 A responder SHOULD always apply the lowest numbered selection 249 mechanism that results in the selection of a known and supported 250 algorithm that meets the responder's criteria for cryptographic 251 algorithm strength. 253 5.2 Static Response 255 For purposes of efficiency, an OCSP responder is permitted to 256 generate static responses in advance of a request. The case may not 257 permit the responder to make use of the client request data during 258 the response generation, however the responder SHOULD still use the 259 client request data during the selection of the pre-generated 260 response to be returned. Responders MAY use the historical client 261 requests as part of the input to the decisions of what different 262 algorithms should be used to sign the pre-generated responses. 264 6 Acknowledgements 266 The authors acknowledges Santosh Chokhani for the helpful comments 267 made on earlier drafts, Sean Turner for proposing the syntax for 268 algorithm identifiers, Jim Schaad for providing and testing the ASN.1 269 module in Annex A and Stephen Kent for valuable review and input. 271 7 IANA Considerations 273 This document requires no actions by IANA. 275 8 Security Considerations 277 The mechanism used to choose the response signing algorithm MUST be 278 considered to be sufficiently secure against cryptanalytic attack for 279 the intended application. 281 In most applications it is sufficient for the signing algorithm to be 282 at least as secure as the signing algorithm used to sign the original 283 certificate whose status is being queried. This criteria may not 284 hold in long term archival applications however in which the status 285 of a certificate is being queried for a date in the distant past, 286 long after the signing algorithm has ceased being considered 287 trustworthy. 289 8.1 Use of insecure algorithms 291 It is not always possible for a responder to generate a response that 292 the client is expected to understand and that meets contemporary 293 standards for cryptographic security. In such cases an OCSP 294 responder operator MUST balance the risk of employing a compromised 295 security solution and the cost of mandating an upgrade, including the 296 risk that the alternative chosen by end users will offer even less 297 security or no security. 299 In archival applications it is quite possible that an OCSP responder 300 might be asked to report the validity of a certificate on a date in 301 the distant past. Such a certificate might employ a signing method 302 that is no longer considered acceptably secure. In such 303 circumstances the responder MUST NOT generate a signature using a 304 signing mechanism that is not considered acceptably secure. 306 A client MUST accept any signing algorithm in a response that it 307 specified as a preferred signing algorithm in the request. It 308 follows therefore that a client MUST NOT specify as a preferred 309 signing algorithm any algorithm that is either not supported or not 310 considered acceptably secure. 312 8.2 Man in the Middle Downgrade Attack 314 The mechanism to support client indication of preferred signature 315 algorithms is not protected against a man in the middle downgrade 316 attack. This constraint is not considered to be a significant 317 security concern since the OCSP responder MUST NOT sign OCSP 318 Responses using weak algorithms even if requested by the client. In 319 addition, the client can reject OCSP responses that do not meet its 320 own criteria for acceptable cryptographic security no matter what 321 mechanism is used to determine the signing algorithm of the response. 323 8.3. Denial of Service Attack 325 Algorithm agility mechanisms defined in this document introduces a 326 slightly increased attack surface for Denial-of-Service attacks where 327 the client request is altered to require algorithms that are not 328 supported by the server. Denial-of-Service considerations from RFC 329 4732 [RFC4732] are relevant for this document. 331 9 References 333 9.1 Normative References 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, March 1997. 338 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 339 Adams, "X.509 Internet Public Key Infrastructure Online 340 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 342 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 343 Identifiers for the Internet X.509 Public Key 344 Infrastructure Certificate and Certificate Revocation List 345 (CRL) Profile", RFC 3279, April 2002. 347 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 348 Algorithms and Identifiers for RSA Cryptography for use in 349 the Internet X.509 Public Key Infrastructure Certificate 350 and Certificate Revocation List (CRL) Profile", RFC 4055, 351 June 2005. 353 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 354 Housley, R., and W. Polk, "Internet X.509 Public Key 355 Infrastructure Certificate and Certificate Revocation List 356 (CRL) Profile", RFC 5280, May 2008. 358 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 359 Mail Extensions (S/MIME) Version 3.2 Message 360 Specification", RFC 5751, January 2010. 362 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 363 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 364 June 2010. 366 9.2 Informative References 368 [RFC2459] Housley, R., Ford, W., Polk, W., and D. Solo, "Internet 369 X.509 Public Key Infrastructure Certificate and CRL 370 Profile", RFC 2459, January 1999. Obsoleted by RFC3280. 372 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 373 Denial-of-Service Considerations", RFC 4732, December 374 2006. 376 Appendix A - ASN.1 Modules 378 A.1 ASN.1 Module 380 OCSP-AGILITY-2009 { iso(1) identified-organization(3) dod(6) 381 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 382 id-mod-ocsp-agility-2009-93(66) } 384 DEFINITIONS EXPLICIT TAGS ::= 385 BEGIN 387 EXPORTS ALL; -- export all items from this module 388 IMPORTS 390 id-pkix-ocsp 391 FROM OCSP-2009 -- From OCSP [RFC2560] 392 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 393 mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp-02(48) } 395 AlgorithmIdentifier{}, SMIMECapability{}, SIGNATURE-ALGORITHM, 396 PUBLIC-KEY 397 FROM AlgorithmInformation-2009 -- From [RFC5912] 398 { iso(1) identified-organization(3) dod(6) internet(1) 399 security(5) mechanisms(5) pkix(7) id-mod(0) 400 id-mod-algorithmInformation-02(58) } 402 EXTENSION 403 FROM PKIX-CommonTypes-2009 -- From [RFC5912] 404 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 405 mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)} ; 407 -- Add re-preferred-signature-algorithms to the set of extensions 408 -- for TBSRequest.requestExtensions 410 re-preferred-signature-algorithms EXTENSION ::= { 411 SYNTAX PreferredSignatureAlgorithms 412 IDENTIFIED BY id-pkix-ocsp-pref-sig-algs } 414 id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 } 416 PreferredSignatureAlgorithms ::= SEQUENCE OF 417 PreferredSignatureAlgorithm 419 PreferredSignatureAlgorithm ::= SEQUENCE { 420 sigIdentifier AlgorithmIdentifier{SIGNATURE-ALGORITHM, {...}}, 421 pubKeyAlgIdentifier SMIMECapability{PUBLIC-KEY, {...}} OPTIONAL } 423 END 425 A.2 1988 ASN.1 Module 427 OCSP-AGILITY-88 { iso(1) identified-organization(3) dod(6) internet(1) 428 security(5) mechanisms(5) pkix(7) id-mod(0) 429 id-mod-ocsp-agility-2009-88(67) } 431 DEFINITIONS EXPLICIT TAGS ::= 432 BEGIN 434 -- EXPORTS ALL; 435 IMPORTS 437 id-pkix-ocsp -- From [RFC2560] 438 FROM OCSP 439 { iso(1) identified-organization(3) dod(6) internet(1) 440 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp(14)} 442 AlgorithmIdentifier 443 FROM PKIX1Explicit88 -- From [RFC5280] 444 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 445 mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) }; 447 SMIMECapability 448 FROM SecureMimeMessageV3dot1 -- From [RFC5751] 449 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 450 smime(16) modules(0) msg-v3dot1(21) } 452 id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 } 454 PreferredSignatureAlgorithms ::= SEQUENCE OF 455 PreferredSignatureAlgorithm 457 PreferredSignatureAlgorithm ::= SEQUENCE { 458 sigIdentifier AlgorithmIdentifier, 459 pubKeyAlgIdentifier SMIMECapability OPTIONAL 460 } 462 END 464 Author's Address 466 Stefan Santesson 467 3xA Security AB 468 Sweden 470 Email: sts@aaa-sec.com 472 Phillip Hallam-Baker 473 Default Deny Security 475 Email: phill@hallambaker.com