idnits 2.17.1 draft-jones-jose-json-private-key-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The "d" (ECC private key) member contains the Elliptic Curve private key value. It is represented as the base64url encoding of the value's unsigned big endian representation as a byte array. The array representation MUST not be shortened to omit any leading zero bytes. For instance, when representing 521 bit integers, the byte array to be base64url encoded MUST contain 66 bytes, including any leading zero bytes. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The "d" (private exponent) member contains the private exponent value for the RSA private key. It is represented as the base64url encoding of the value's unsigned big endian representation as a byte array. The array representation MUST not be shortened to omit any leading zero bytes. For instance, when representing 2048 bit integers, the byte array to be base64url encoded MUST contain 256 bytes, including any leading zero bytes. -- The document date (November 6, 2012) is 4181 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. 'JWA' -- Possible downref: Non-RFC (?) normative reference: ref. 'JWK' ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 JOSE Working Group M. Jones 3 Internet-Draft Microsoft 4 Intended status: Standards Track November 6, 2012 5 Expires: May 10, 2013 7 JSON Private Key 8 draft-jones-jose-json-private-key-01 10 Abstract 12 The JSON Private Key specification extends the JSON Web Key (JWK) and 13 JSON Web Algorithms (JWA) specifications to define a JavaScript 14 Object Notation (JSON) representation of private keys. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on May 10, 2013. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. JWK Parameters for Private Keys . . . . . . . . . . . . . . . . 3 54 3.1. JWK Parameters for Elliptic Curve Private Keys . . . . . . 3 55 3.1.1. "d" (ECC Private Key) Parameter . . . . . . . . . . . . 3 56 3.2. JWK Parameters for RSA Private Keys . . . . . . . . . . . . 3 57 3.2.1. "d" (Private Exponent) Parameter . . . . . . . . . . . 4 58 3.2.2. "p" (First Prime Factor) Parameter . . . . . . . . . . 4 59 3.2.3. "q" (Second Prime Factor) Parameter . . . . . . . . . . 4 60 3.2.4. "dp" (First Factor CRT Exponent) Parameter . . . . . . 4 61 3.2.5. "dq" (Second Factor CRT Exponent) Parameter . . . . . . 4 62 3.2.6. "qi" (First CRT Coefficient) Parameter . . . . . . . . 4 63 3.2.7. "oth" (Other Primes Info) Parameter . . . . . . . . . . 4 64 3.2.7.1. "r" (Prime Factor) . . . . . . . . . . . . . . . . 5 65 3.2.7.2. "d" (Factor CRT Exponent) . . . . . . . . . . . . . 5 66 3.2.7.3. "t" (Factor CRT Coefficient) . . . . . . . . . . . 5 67 4. Example Private Keys . . . . . . . . . . . . . . . . . . . . . 5 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 69 5.1. JSON Web Key Parameters Registration . . . . . . . . . . . 7 70 5.1.1. Registry Contents . . . . . . . . . . . . . . . . . . . 7 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 72 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8 73 Appendix A. Document History . . . . . . . . . . . . . . . . . . . 8 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 The JSON Private Key specification extends the JSON Web Key (JWK) 79 [JWK] and JSON Web Algorithms (JWA) [JWA] specifications to define a 80 JavaScript Object Notation (JSON) [RFC4627] representation of private 81 keys. 83 1.1. Notational Conventions 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in Key words for use in 88 RFCs to Indicate Requirement Levels [RFC2119]. 90 2. Terminology 92 This specification uses the same terminology as the JSON Web Key 93 (JWK) [JWK] and JSON Web Algorithms (JWA) [JWA] specifications. 95 3. JWK Parameters for Private Keys 97 This section defines additional JSON Web Key parameters that enable 98 JWKs to represent private keys. 100 3.1. JWK Parameters for Elliptic Curve Private Keys 102 When the JWK "alg" member value is "EC", the following member MAY be 103 used to represent an Elliptic Curve private key: 105 3.1.1. "d" (ECC Private Key) Parameter 107 The "d" (ECC private key) member contains the Elliptic Curve private 108 key value. It is represented as the base64url encoding of the 109 value's unsigned big endian representation as a byte array. The 110 array representation MUST not be shortened to omit any leading zero 111 bytes. For instance, when representing 521 bit integers, the byte 112 array to be base64url encoded MUST contain 66 bytes, including any 113 leading zero bytes. 115 3.2. JWK Parameters for RSA Private Keys 117 When the JWK "alg" member value is "RSA", the following member MAY be 118 used to represent an RSA private key: 120 3.2.1. "d" (Private Exponent) Parameter 122 The "d" (private exponent) member contains the private exponent value 123 for the RSA private key. It is represented as the base64url encoding 124 of the value's unsigned big endian representation as a byte array. 125 The array representation MUST not be shortened to omit any leading 126 zero bytes. For instance, when representing 2048 bit integers, the 127 byte array to be base64url encoded MUST contain 256 bytes, including 128 any leading zero bytes. 130 3.2.2. "p" (First Prime Factor) Parameter 132 The "p" (first prime factor) member contains the first prime factor, 133 a positive integer. It is represented as the base64url encoding of 134 the value's unsigned big endian representation as a byte array. 136 3.2.3. "q" (Second Prime Factor) Parameter 138 The "q" (second prime factor) member contains the second prime 139 factor, a positive integer. It is represented as the base64url 140 encoding of the value's unsigned big endian representation as a byte 141 array. 143 3.2.4. "dp" (First Factor CRT Exponent) Parameter 145 The "dp" (first factor CRT exponent) member contains the Chinese 146 Remainder Theorem (CRT) exponent of the first factor, a positive 147 integer. It is represented as the base64url encoding of the value's 148 unsigned big endian representation as a byte array. 150 3.2.5. "dq" (Second Factor CRT Exponent) Parameter 152 The "dq" (second factor CRT exponent) member contains the Chinese 153 Remainder Theorem (CRT) exponent of the second factor, a positive 154 integer. It is represented as the base64url encoding of the value's 155 unsigned big endian representation as a byte array. 157 3.2.6. "qi" (First CRT Coefficient) Parameter 159 The "dp" (first CRT coefficient) member contains the Chinese 160 Remainder Theorem (CRT) coefficient of the second factor, a positive 161 integer. It is represented as the base64url encoding of the value's 162 unsigned big endian representation as a byte array. 164 3.2.7. "oth" (Other Primes Info) Parameter 166 The "oth" (other primes info) member contains an array of information 167 about any third and subsequent primes, should they exist. When only 168 two primes have been used (the normal case), this parameter MUST be 169 omitted. When three or more primes have been used, the number of 170 array elements MUST be the number of primes used minus two. Each 171 array element MUST be an object with the following members: 173 3.2.7.1. "r" (Prime Factor) 175 The "r" (prime factor) parameter within an "oth" array member 176 represents the value of a subsequent prime factor, a positive 177 integer. It is represented as the base64url encoding of the value's 178 unsigned big endian representation as a byte array. 180 3.2.7.2. "d" (Factor CRT Exponent) 182 The "d" (Factor CRT Exponent) parameter within an "oth" array member 183 represents the CRT exponent of the corresponding prime factor, a 184 positive integer. It is represented as the base64url encoding of the 185 value's unsigned big endian representation as a byte array. 187 3.2.7.3. "t" (Factor CRT Coefficient) 189 The "t" (factor CRT coefficient) parameter within an "oth" array 190 member represents the CRT coefficient of the corresponding prime 191 factor, a positive integer. It is represented as the base64url 192 encoding of the value's unsigned big endian representation as a byte 193 array. 195 4. Example Private Keys 197 The following example JWK Set contains two keys represented as JWKs 198 containing both public and private key values: one using an Elliptic 199 Curve algorithm and a second one using an RSA algorithm. This 200 example extends the example in Section 3 of [JWK], adding private key 201 values. (Line breaks are for display purposes only.) 202 {"keys": 203 [ 204 {"alg":"EC", 205 "crv":"P-256", 206 "x":"MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4", 207 "y":"4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM", 208 "d":"870MB6gfuTJ4HtUnUvYMyJpr5eUZNP4Bk43bVdj3eAE", 209 "use":"enc", 210 "kid":"1"}, 212 {"alg":"RSA", 213 "n":"0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx4 214 cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMst 215 n64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2Q 216 vzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbIS 217 D08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqbw 218 0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw", 219 "e":"AQAB", 220 "d":"X4cTteJY_gn4FYPsXB8rdXix5vwsg1FLN5E3EaG6RJoVH-HLLKD9 221 M7dx5oo7GURknchnrRweUkC7hT5fJLM0WbFAKNLWY2vv7B6NqXSzUvxT0_YSfqij 222 wp3RTzlBaCxWp4doFk5N2o8Gy_nHNKroADIkJ46pRUohsXywbReAdYaMwFs9tv8d 223 _cPVY3i07a3t8MN6TNwm0dSawm9v47UiCl3Sk5ZiG7xojPLu4sbg1U2jx4IBTNBz 224 nbJSzFHK66jT8bgkuqsk0GjskDJk19Z4qwjwbsnn4j2WBii3RL-Us2lGVkY8fkFz 225 me1z0HbIkfz0Y6mqnOYtqc0X4jfcKoAC8Q", 226 "p":"83i-7IvMGXoMXCskv73TKr8637FiO7Z27zv8oj6pbWUQyLPQBQxtPV 227 nwD20R-60eTDmD2ujnMt5PoqMrm8RfmNhVWDtjjMmCMjOpSXicFHj7XOuVIYQyqV 228 WlWEh6dN36GVZYk93N8Bc9vY41xy8B9RzzOGVQzXvNEvn7O0nVbfs", 229 "q":"3dfOR9cuYq-0S-mkFLzgItgMEfFzB2q3hWehMuG0oCuqnb3vobLyum 230 qjVZQO1dIrdwgTnCdpYzBcOfW5r370AFXjiWft_NGEiovonizhKpo9VVS78TzFgx 231 kIdrecRezsZ-1kYd_s1qDbxtkDEgfAITAG9LUnADun4vIcb6yelxk", 232 "dp":"G4sPXkc6Ya9y8oJW9_ILj4xuppu0lzi_H7VTkS8xj5SdX3coE0oim 233 YwxIi2emTAue0UOa5dpgFGyBJ4c8tQ2VF402XRugKDTP8akYhFo5tAA77Qe_Nmtu 234 YZc3C3m3I24G2GvR5sSDxUyAN2zq8Lfn9EUms6rY3Ob8YeiKkTiBj0", 235 "dq":"s9lAH9fggBsoFR8Oac2R_E2gw282rT2kGOAhvIllETE1efrA6huUU 236 vMfBcMpn8lqeW6vzznYY5SSQF7pMdC_agI3nG8Ibp1BUb0JUiraRNqUfLhcQb_d9 237 GF4Dh7e74WbRsobRonujTYN1xCaP6TO61jvWrX-L18txXw494Q_cgk", 238 "qi":"GyM_p6JrXySiz1toFgKbWV-JdI3jQ4ypu9rbMWx3rQJBfmt0FoYzg 239 UIZEVFEcOqwemRN81zoDAaa-Bk0KWNGDjJHZDdDmFhW3AN7lI-puxk_mHZGJ11rx 240 yR8O55XLSe3SPmRfKwZI6yU24ZxvQKFYItdldUKGzO6Ia6zTKhAVRU", 241 "kid":"2011-04-29"} 242 ] 243 } 245 5. IANA Considerations 246 5.1. JSON Web Key Parameters Registration 248 This specification registers the parameter names defined in 249 Section 3.1 and Section 3.2 in the IANA JSON Web Key Parameters 250 registry [JWK]. 252 5.1.1. Registry Contents 254 o Parameter Name: "d" 255 o Change Controller: IETF 256 o Specification Document(s): Section 3.1.1 of [[ this document ]] 258 o Parameter Name: "d" 259 o Change Controller: IETF 260 o Specification Document(s): Section 3.2.1 of [[ this document ]] 262 o Parameter Name: "p" 263 o Change Controller: IETF 264 o Specification Document(s): Section 3.2.2 of [[ this document ]] 266 o Parameter Name: "q" 267 o Change Controller: IETF 268 o Specification Document(s): Section 3.2.3 of [[ this document ]] 270 o Parameter Name: "dp" 271 o Change Controller: IETF 272 o Specification Document(s): Section 3.2.4 of [[ this document ]] 274 o Parameter Name: "dq" 275 o Change Controller: IETF 276 o Specification Document(s): Section 3.2.5 of [[ this document ]] 278 o Parameter Name: "qi" 279 o Change Controller: IETF 280 o Specification Document(s): Section 3.2.6 of [[ this document ]] 282 o Parameter Name: "oth" 283 o Change Controller: IETF 284 o Specification Document(s): Section 3.2.7 of [[ this document ]] 286 6. Security Considerations 288 The security considerations for this specification are the same as 289 those for the JSON Web Key (JWK) [JWK] specification and the portion 290 of the JSON Web Algorithms (JWA) [JWA] specification that pertains to 291 key representations. 293 7. Normative References 295 [JWA] Jones, M., "JSON Web Algorithms (JWA)", November 2012. 297 [JWK] Jones, M., "JSON Web Key (JWK)", November 2012. 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, March 1997. 302 [RFC4627] Crockford, D., "The application/json Media Type for 303 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 305 Appendix A. Document History 307 [[ to be removed by the RFC editor before publication as an RFC ]] 309 -01 311 o Changed the names of the RSA key parameters so that the 312 identifiers are the same as those used in RFC 3447. 314 o Added the RSA private key fields enabling Chinese Remainder 315 Theorem (CRT) calculations, based upon their use in RFC 3447. 317 -00 319 o Created draft-jones-jose-json-private-key to facilitate discussion 320 of the question from the W3C WebCrypto WG to the IETF JOSE WG of 321 whether JOSE plans to support a format for representing private 322 keys. 324 Author's Address 326 Michael B. Jones 327 Microsoft 329 Email: mbj@microsoft.com 330 URI: http://self-issued.info/