idnits 2.17.1 draft-jones-jose-json-private-and-symmetric-key-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 : ---------------------------------------------------------------------------- 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 (December 27, 2012) is 4137 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 3447 (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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 December 27, 2012 5 Expires: June 30, 2013 7 JSON Private and Symmetric Key 8 draft-jones-jose-json-private-and-symmetric-key-00 10 Abstract 12 The JSON Private Key specification extends the JSON Web Key (JWK) and 13 JSON Web Algorithms (JWA) specifications to define JavaScript Object 14 Notation (JSON) representations of private keys and symmetric 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 June 30, 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. JWK Parameters for Symmetric Keys . . . . . . . . . . . . . . 5 68 4.1. "k" (Key Value) Parameter . . . . . . . . . . . . . . . . 5 69 5. Example Private Keys . . . . . . . . . . . . . . . . . . . . . 5 70 6. Example Symmetric Keys . . . . . . . . . . . . . . . . . . . . 7 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 7.1. JSON Web Key Types Registration . . . . . . . . . . . . . 7 73 7.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 7 74 7.2. JSON Web Key Parameters Registration . . . . . . . . . . . 7 75 7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 7 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 9. Normative References . . . . . . . . . . . . . . . . . . . . . 9 78 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 79 Appendix B. Document History . . . . . . . . . . . . . . . . . . 9 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 1. Introduction 84 The JSON Private Key specification extends the JSON Web Key (JWK) 85 [JWK] and JSON Web Algorithms (JWA) [JWA] specifications to define 86 JavaScript Object Notation (JSON) [RFC4627] representations of 87 private and symmetric keys. 89 1.1. Notational Conventions 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in Key words for use in 94 RFCs to Indicate Requirement Levels [RFC2119]. 96 2. Terminology 98 This specification uses the same terminology as the JSON Web Key 99 (JWK) [JWK] and JSON Web Algorithms (JWA) [JWA] specifications. 101 3. JWK Parameters for Private Keys 103 This section defines additional JSON Web Key parameters that enable 104 JWKs to represent private keys. 106 3.1. JWK Parameters for Elliptic Curve Private Keys 108 When the JWK "kty" member value is "EC", the following member MAY be 109 used to represent an Elliptic Curve private key: 111 3.1.1. "d" (ECC Private Key) Parameter 113 The "d" (ECC private key) member contains the Elliptic Curve private 114 key value. It is represented as the base64url encoding of the 115 value's unsigned big endian representation as a byte array. The 116 array representation MUST not be shortened to omit any leading zero 117 bytes. For instance, when representing 521 bit integers, the byte 118 array to be base64url encoded MUST contain 66 bytes, including any 119 leading zero bytes. 121 3.2. JWK Parameters for RSA Private Keys 123 When the JWK "kty" member value is "RSA", the following member MAY be 124 used to represent an RSA private key: 126 3.2.1. "d" (Private Exponent) Parameter 128 The "d" (private exponent) member contains the private exponent value 129 for the RSA private key. It is represented as the base64url encoding 130 of the value's unsigned big endian representation as a byte array. 131 The array representation MUST not be shortened to omit any leading 132 zero bytes. For instance, when representing 2048 bit integers, the 133 byte array to be base64url encoded MUST contain 256 bytes, including 134 any leading zero bytes. 136 3.2.2. "p" (First Prime Factor) Parameter 138 The "p" (first prime factor) member contains the first prime factor, 139 a positive integer. It is represented as the base64url encoding of 140 the value's unsigned big endian representation as a byte array. 142 3.2.3. "q" (Second Prime Factor) Parameter 144 The "q" (second prime factor) member contains the second prime 145 factor, a positive integer. It is represented as the base64url 146 encoding of the value's unsigned big endian representation as a byte 147 array. 149 3.2.4. "dp" (First Factor CRT Exponent) Parameter 151 The "dp" (first factor CRT exponent) member contains the Chinese 152 Remainder Theorem (CRT) exponent of the first factor, a positive 153 integer. It is represented as the base64url encoding of the value's 154 unsigned big endian representation as a byte array. 156 3.2.5. "dq" (Second Factor CRT Exponent) Parameter 158 The "dq" (second factor CRT exponent) member contains the Chinese 159 Remainder Theorem (CRT) exponent of the second factor, a positive 160 integer. It is represented as the base64url encoding of the value's 161 unsigned big endian representation as a byte array. 163 3.2.6. "qi" (First CRT Coefficient) Parameter 165 The "dp" (first CRT coefficient) member contains the Chinese 166 Remainder Theorem (CRT) coefficient of the second factor, a positive 167 integer. It is represented as the base64url encoding of the value's 168 unsigned big endian representation as a byte array. 170 3.2.7. "oth" (Other Primes Info) Parameter 172 The "oth" (other primes info) member contains an array of information 173 about any third and subsequent primes, should they exist. When only 174 two primes have been used (the normal case), this parameter MUST be 175 omitted. When three or more primes have been used, the number of 176 array elements MUST be the number of primes used minus two. Each 177 array element MUST be an object with the following members: 179 3.2.7.1. "r" (Prime Factor) 181 The "r" (prime factor) parameter within an "oth" array member 182 represents the value of a subsequent prime factor, a positive 183 integer. It is represented as the base64url encoding of the value's 184 unsigned big endian representation as a byte array. 186 3.2.7.2. "d" (Factor CRT Exponent) 188 The "d" (Factor CRT Exponent) parameter within an "oth" array member 189 represents the CRT exponent of the corresponding prime factor, a 190 positive integer. It is represented as the base64url encoding of the 191 value's unsigned big endian representation as a byte array. 193 3.2.7.3. "t" (Factor CRT Coefficient) 195 The "t" (factor CRT coefficient) parameter within an "oth" array 196 member represents the CRT coefficient of the corresponding prime 197 factor, a positive integer. It is represented as the base64url 198 encoding of the value's unsigned big endian representation as a byte 199 array. 201 4. JWK Parameters for Symmetric Keys 203 When the JWK "kty" member value is "oct" (octet sequence), the 204 following member MAY be used to represent a symmetric key (or another 205 key whose value is a single octet sequence): 207 4.1. "k" (Key Value) Parameter 209 The "k" (key value) member contains the value of the symmetric (or 210 other single-valued) key. It is represented as the base64url 211 encoding of the octet sequence containing the key value. 213 5. Example Private Keys 215 The following example JWK Set contains two keys represented as JWKs 216 containing both public and private key values: one using an Elliptic 217 Curve algorithm and a second one using an RSA algorithm. This 218 example extends the example in Section 3 of [JWK], adding private key 219 values. (Line breaks are for display purposes only.) 220 {"keys": 221 [ 222 {"kty":"EC", 223 "crv":"P-256", 224 "x":"MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4", 225 "y":"4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM", 226 "d":"870MB6gfuTJ4HtUnUvYMyJpr5eUZNP4Bk43bVdj3eAE", 227 "use":"enc", 228 "kid":"1"}, 230 {"kty":"RSA", 231 "n":"0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx4 232 cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMst 233 n64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2Q 234 vzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbIS 235 D08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqbw 236 0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw", 237 "e":"AQAB", 238 "d":"X4cTteJY_gn4FYPsXB8rdXix5vwsg1FLN5E3EaG6RJoVH-HLLKD9 239 M7dx5oo7GURknchnrRweUkC7hT5fJLM0WbFAKNLWY2vv7B6NqXSzUvxT0_YSfqij 240 wp3RTzlBaCxWp4doFk5N2o8Gy_nHNKroADIkJ46pRUohsXywbReAdYaMwFs9tv8d 241 _cPVY3i07a3t8MN6TNwm0dSawm9v47UiCl3Sk5ZiG7xojPLu4sbg1U2jx4IBTNBz 242 nbJSzFHK66jT8bgkuqsk0GjskDJk19Z4qwjwbsnn4j2WBii3RL-Us2lGVkY8fkFz 243 me1z0HbIkfz0Y6mqnOYtqc0X4jfcKoAC8Q", 244 "p":"83i-7IvMGXoMXCskv73TKr8637FiO7Z27zv8oj6pbWUQyLPQBQxtPV 245 nwD20R-60eTDmD2ujnMt5PoqMrm8RfmNhVWDtjjMmCMjOpSXicFHj7XOuVIYQyqV 246 WlWEh6dN36GVZYk93N8Bc9vY41xy8B9RzzOGVQzXvNEvn7O0nVbfs", 247 "q":"3dfOR9cuYq-0S-mkFLzgItgMEfFzB2q3hWehMuG0oCuqnb3vobLyum 248 qjVZQO1dIrdwgTnCdpYzBcOfW5r370AFXjiWft_NGEiovonizhKpo9VVS78TzFgx 249 kIdrecRezsZ-1kYd_s1qDbxtkDEgfAITAG9LUnADun4vIcb6yelxk", 250 "dp":"G4sPXkc6Ya9y8oJW9_ILj4xuppu0lzi_H7VTkS8xj5SdX3coE0oim 251 YwxIi2emTAue0UOa5dpgFGyBJ4c8tQ2VF402XRugKDTP8akYhFo5tAA77Qe_Nmtu 252 YZc3C3m3I24G2GvR5sSDxUyAN2zq8Lfn9EUms6rY3Ob8YeiKkTiBj0", 253 "dq":"s9lAH9fggBsoFR8Oac2R_E2gw282rT2kGOAhvIllETE1efrA6huUU 254 vMfBcMpn8lqeW6vzznYY5SSQF7pMdC_agI3nG8Ibp1BUb0JUiraRNqUfLhcQb_d9 255 GF4Dh7e74WbRsobRonujTYN1xCaP6TO61jvWrX-L18txXw494Q_cgk", 256 "qi":"GyM_p6JrXySiz1toFgKbWV-JdI3jQ4ypu9rbMWx3rQJBfmt0FoYzg 257 UIZEVFEcOqwemRN81zoDAaa-Bk0KWNGDjJHZDdDmFhW3AN7lI-puxk_mHZGJ11rx 258 yR8O55XLSe3SPmRfKwZI6yU24ZxvQKFYItdldUKGzO6Ia6zTKhAVRU", 259 "alg":"RS256", 260 "kid":"2011-04-29"} 261 ] 262 } 264 6. Example Symmetric Keys 266 The following example JWK Set contains two symmetric keys represented 267 as JWKs: one designated as being for use with the AES Key Wrap 268 algorithm and a second one that is an HMAC key. (Line breaks are for 269 display purposes only.) 271 {"keys": 272 [ 273 {"kty":"oct", 274 "alg":"A128KW", 275 "k":"GawgguFyGrWKav7AX4VKUg"}, 277 {"kty":"oct", 278 "k":"AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75 279 aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow", 280 "kid":"HMAC key used in JWS A.1 example"} 281 ] 282 } 284 7. IANA Considerations 286 7.1. JSON Web Key Types Registration 288 This specification registers the key type defined in Section 4 in the 289 IANA JSON Web Key Types registry [JWA]. 291 7.1.1. Registry Contents 293 o "kty" Parameter Value: "oct" 294 o Implementation Requirements: RECOMMENDED+ 295 o Change Controller: IETF 296 o Specification Document(s): Section 4 of [[ this document ]] 298 7.2. JSON Web Key Parameters Registration 300 This specification registers the parameter names defined in 301 Section 3.1, Section 3.2, and Section 4 in the IANA JSON Web Key 302 Parameters registry [JWK]. 304 7.2.1. Registry Contents 306 o Parameter Name: "d" 307 o Change Controller: IETF 308 o Specification Document(s): Section 3.1.1 of [[ this document ]] 309 o Parameter Name: "d" 310 o Change Controller: IETF 311 o Specification Document(s): Section 3.2.1 of [[ this document ]] 313 o Parameter Name: "p" 314 o Change Controller: IETF 315 o Specification Document(s): Section 3.2.2 of [[ this document ]] 317 o Parameter Name: "q" 318 o Change Controller: IETF 319 o Specification Document(s): Section 3.2.3 of [[ this document ]] 321 o Parameter Name: "dp" 322 o Change Controller: IETF 323 o Specification Document(s): Section 3.2.4 of [[ this document ]] 325 o Parameter Name: "dq" 326 o Change Controller: IETF 327 o Specification Document(s): Section 3.2.5 of [[ this document ]] 329 o Parameter Name: "qi" 330 o Change Controller: IETF 331 o Specification Document(s): Section 3.2.6 of [[ this document ]] 333 o Parameter Name: "oth" 334 o Change Controller: IETF 335 o Specification Document(s): Section 3.2.7 of [[ this document ]] 337 o Parameter Name: "k" 338 o Change Controller: IETF 339 o Specification Document(s): Section 4.1 of [[ this document ]] 341 8. Security Considerations 343 All of the security issues faced by any cryptographic application 344 must be faced by a JWS/JWE/JWK agent. Among these issues are 345 protecting the user's private and symmetric keys, preventing various 346 attacks, and helping the user avoid mistakes such as inadvertently 347 encrypting a message for the wrong recipient. The entire list of 348 security considerations is beyond the scope of this document. 350 Private and symmetric keys must be protected from disclosure to 351 unintended parties. One recommended means of doing so is to encrypt 352 JWKs or JWK Sets containing them by using the JWK or JWK Set value as 353 the plaintext of a JWE. 355 A key is no more trustworthy than the method by which it was 356 received. 358 The security considerations in RFC 3447 [RFC3447] and RFC 6030 359 [RFC6030] about protecting private and symmetric keys also apply to 360 this specification. 362 9. Normative References 364 [JWA] Jones, M., "JSON Web Algorithms (JWA)", 365 draft-ietf-jose-json-web-algorithms (work in progress), 366 December 2012. 368 [JWK] Jones, M., "JSON Web Key (JWK)", 369 draft-ietf-jose-json-web-key (work in progress), 370 December 2012. 372 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 373 Requirement Levels", BCP 14, RFC 2119, March 1997. 375 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 376 Standards (PKCS) #1: RSA Cryptography Specifications 377 Version 2.1", RFC 3447, February 2003. 379 [RFC4627] Crockford, D., "The application/json Media Type for 380 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 382 [RFC6030] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric 383 Key Container (PSKC)", RFC 6030, October 2010. 385 Appendix A. Acknowledgements 387 John Bradley and James Manger contributed to the contents of this 388 specification. 390 Appendix B. Document History 392 [[ to be removed by the RFC editor before publication as an RFC ]] 394 -00 396 o Created draft-jones-jose-json-private-and-symmetric-key from 397 draft-jones-jose-json-private-key, adding a representation for 398 symmetric keys. 400 o Tracked parameter changes and additions in the JWK spec. 402 o Recommend encryption of JWKs and JWK Sets containing private or 403 symmetric keys as JWEs. 405 o Added seriesInfo information to Internet Draft references. 407 draft-jones-jose-json-private-key-01 409 o Changed the names of the RSA key parameters so that the 410 identifiers are the same as those used in RFC 3447. 412 o Added the RSA private key fields enabling Chinese Remainder 413 Theorem (CRT) calculations, based upon their use in RFC 3447. 415 draft-jones-jose-json-private-key-00 417 o Created draft-jones-jose-json-private-key to facilitate discussion 418 of the question from the W3C WebCrypto WG to the IETF JOSE WG of 419 whether JOSE plans to support a format for representing private 420 keys. 422 Author's Address 424 Michael B. Jones 425 Microsoft 427 Email: mbj@microsoft.com 428 URI: http://self-issued.info/