idnits 2.17.1 draft-peck-ecdhpop-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 date (October 2, 2013) is 3859 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186' ** Downref: Normative reference to an Informational RFC: RFC 2986 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT M. Peck 3 Intended Status: Proposed Standard The MITRE Corporation 4 Expires: April 5, 2014 October 2, 2013 6 Elliptic Curve Diffie-Hellman Proof-of-Possession Method 7 draft-peck-ecdhpop-01 9 Abstract 11 This document specifies a proof-of-possession mechanism for 12 requesting Elliptic Curve Diffie-Hellman X.509 public key 13 certificates using the PKCS #10 and CRMF syntaxes. 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Copyright and License Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . . . . . 3 56 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5.1. Normative References . . . . . . . . . . . . . . . . . . . 5 60 5.2. Informative References . . . . . . . . . . . . . . . . . . 6 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 63 1. Introduction 65 PKCS #10 [RFC2986] and the Certificate Request Message Format (CRMF) 66 [RFC4211] are two syntaxes for requesting X.509 public key 67 certificates. 69 Public Key Infrastructure (PKI) policies commonly require that 70 certificate requesters prove possession of the private key 71 corresponding to the public key in the request. 73 In the case of a signature certificate request, the requester 74 typically provides a digital signature, computed using the private 75 key corresponding to the public key in the certificate request, as 76 proof of possession. 78 In the case of a key agreement certificate request, it is possible to 79 provide proof of possession of the private key by performing a key 80 agreement operation. However, doing so adds complexity. A simpler 81 method of providing proof of possession is to perform a one-time 82 digital signature using the private key. 84 [RFC6955] defines mechanisms to perform proof-of-possession using a 85 key agreement operation for Diffie-Hellman and Elliptic Curve Diffie- 86 Hellman keys, and a mechanism to perform proof-of-possession using a 87 digital signature for Diffie-Hellman keys. However, it does not 88 define a mechanism to perform proof-of-possession using a digital 89 signature algorithm for Elliptic Curve Diffie-Hellman keys. 91 This document defines a mechanism to perform proof of possession for 92 Elliptic Curve Diffie-Hellman certificate requests using the Elliptic 93 Curve Digital Signature Algorithm (ECDSA). This document also 94 defines how to transmit the proof of possession value using both the 95 PKCS #10 and CRMF syntaxes. 97 1.1. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 103 2. Elliptic Curve Diffie-Hellman 105 When using the proof of possession mechanism specified in this 106 section, Elliptic Curve Diffie-Hellman domain parameters MUST be 107 selected from a named curve. [FIPS186] names fifteen curves, and 108 other documents specify other curves. 110 PKCS #10 and CRMF both use a data element of type 111 SubjectPublicKeyInfo to convey the requested public key. The X.509 112 certificate, if issued, will contain the public key in a field of the 113 same type. 115 [RFC5480] Section 2.1.1 specifies how to represent the Elliptic Curve 116 Diffie-Hellman domain parameters and public key within the 117 SubjectPublicKeyInfo data element. 119 The Elliptic Curve Digital Signature Algorithm is specified in 120 [FIPS186]. [RFC6090] specifies a signature algorithm called KT-I 121 that for many hash functions is mathematically and functionally 122 equivalent to ECDSA. An ECDSA digital signature is generated using a 123 set of domain parameters (a curve), a private key, a per-message 124 secret number, a hash function, and the data to be signed. 126 To use ECDSA to perform proof of possession of an Elliptic Curve 127 Diffie-Hellman private key: 129 o Set the ECDSA curve to the same as the ECDH curve. 131 o Set the ECDSA private key to the same as the ECDH private key. 133 o Set the ECDSA per-message secret according to the guidance of 134 [FIPS186]. 136 o Set the hash function depending on the selected curve. The 137 security strength of the chosen hash function MUST be equal to or 138 greater than the security strength associated with the bit length of 139 the domain parameter n. The security considerations section of 140 [RFC5480] provides recommended hash functions to use in conjunction 141 with the NIST curves. 143 o Set the data to be signed according to the guidance provided by 144 PKCS #10 or CRMF. 146 For PKCS #10, set the signatureAlgorithm field to the appropriate 147 ECDSA signature algorithm object identifier depending on the hash 148 function chosen above, and place the generated ECDSA signature in the 149 signature field, following the guidance of [RFC3279] Section 2.2.3. 151 For CRMF, include the popo field within CertReqMsg using the 152 signature (POPOSigningKey) proof-of-possession choice. Set the 153 POPOSigningKey algorithmIdentifier to the appropriate ECDSA signature 154 algorithm object identifier depending on the hash function chosen 155 above, and place the generated ECDSA signature in the POPOSigningKey 156 signature field, following the guidance of [RFC3279] Section 2.2.3. 158 [RFC3279] and [RFC5758] provide ECDSA signature algorithm identifiers 159 paired with various hash functions. Additional ECDSA signature 160 algorithm identifiers may be found in other sources. 162 3. Security Considerations 164 This document specifies proof-of-possession of a key agreement 165 private key by performing a digital signature. Except for one-time 166 proof-of-possession, a single key pair SHOULD NOT be used for both 167 signature and key agreement. NIST Special Publication 800-57 Part 1 168 [SP80057] Section 8.1.5.1.1.2 permits use of a key agreement private 169 key to perform a digital signature for proof-of-possession purposes. 171 This specification requires implementations to generate key pairs and 172 other random values. The use of inadequate pseudo-random number 173 generators (PRNGs) can result in little or no security. The 174 generation of quality random numbers is difficult. [FIPS186] and 175 [RFC4086] offer random number generation guidance. 177 In a substitution attack, as described in [RFC5272] Section 6.3, an 178 attacker may attempt to take a PKCS #10 or CRMF certificate request 179 and change the context in which it is presented to the Certification 180 Authority in order to cause a certificate with incorrect identity 181 information to be generated. In order to thwart this class of 182 attack, the proof-of-possession signature should cover not only the 183 public key itself but also on the requested identity or other 184 information used by the public key infrastructure to assign an 185 identity to the issued certificate. For example, CMC [RFC5272] 186 provides a mechanism to cryptographically bind information from the 187 outer Full PKI Request into the inner PKCS #10 or CRMF message where 188 it is covered by the proof-of-possession signature. The EST protocol 189 [est] provides a similar mechanism to cryptographically bind 190 information from the TLS session into the inner PKCS #10 or CRMF 191 message where it is covered by the proof-of-possession signature. 193 4. IANA Considerations 195 This document has no IANA actions. 197 5. References 199 5.1. Normative References 201 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 202 Requirement Levels", BCP 14, RFC 2119, March 1997. 204 [FIPS186] National Institute of Standards and Technology, FIPS 205 Publication 186-4: "Digital Signature Standard (DSS)", 206 July 2013. 208 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 209 Request Syntax Specification Version 1.7", RFC 2986, 210 November 2000. 212 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 213 Certificate Request Message Format (CRMF)", RFC 4211, 214 September 2005. 216 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 217 "Elliptic Curve Cryptography Subject Public Key 218 Information", RFC 5480, March 2009. 220 5.2. Informative References 222 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 223 Identifiers for the Internet X.509 Public Key 224 Infrastructure Certificate and Certificate Revocation List 225 (CRL) Profile", RFC 3279, April 2002. 227 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 228 "Randomness Requirements for Security", BCP 106, RFC 4086, 229 June 2005. 231 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 232 (CMC)", RFC 5272, June 2008. 234 [RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. 235 Polk, "Internet X.509 Public Key Infrastructure: 236 Additional Algorithms and Identifiers for DSA and ECDSA", 237 RFC 5758, January 2010. 239 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 240 Curve Cryptography Algorithms", RFC 6090, February 2011. 242 [RFC6955] Schaad, J., and H. Prafullchandra, "Diffie-Hellman Proof- 243 of-Possession Algorithms", RFC 6955, May 2013. 245 [SP80057] National Institute of Standards and Technology, Special 246 Publication 800-57 Part 1: "Recommendation for Key 247 Management - Part 1: General (Revision 3)", July 2012. 249 [est] Pritikin, M., Yee, P., and D. Harkins, "Enrollment over 250 Secure Transport", draft-ietf-pkix-est-09, Work in 251 Progress, August 2013. 253 Authors' Addresses 255 Michael Peck 256 The MITRE Corporation 258 EMail: mpeck@mitre.org