idnits 2.17.1 draft-ietf-jose-json-web-key-12.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 (July 11, 2013) is 3941 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. 'ECMAScript' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.X690.1994' ** Downref: Normative reference to an Historic RFC: RFC 1421 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 4 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 July 11, 2013 5 Expires: January 12, 2014 7 JSON Web Key (JWK) 8 draft-ietf-jose-json-web-key-12 10 Abstract 12 A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data 13 structure that represents a cryptographic key. This specification 14 also defines a JSON Web Key Set (JWK Set) JSON data structure for 15 representing a set of JWKs. Cryptographic algorithms and identifiers 16 for use with this specification are described in the separate JSON 17 Web Algorithms (JWA) specification. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 12, 2014. 36 Copyright 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. Notational Conventions . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. JSON Web Key (JWK) Format . . . . . . . . . . . . . . . . . . 4 57 3.1. "kty" (Key Type) Parameter . . . . . . . . . . . . . . . . 4 58 3.2. "use" (Key Use) Parameter . . . . . . . . . . . . . . . . 5 59 3.3. "alg" (Algorithm) Parameter . . . . . . . . . . . . . . . 5 60 3.4. "kid" (Key ID) Parameter . . . . . . . . . . . . . . . . . 5 61 3.5. "x5u" (X.509 URL) Header Parameter . . . . . . . . . . . . 5 62 3.6. "x5t" (X.509 Certificate Thumbprint) Header Parameter . . 6 63 3.7. "x5c" (X.509 Certificate Chain) Parameter . . . . . . . . 6 64 4. JSON Web Key Set (JWK Set) Format . . . . . . . . . . . . . . 6 65 4.1. "keys" (JSON Web Key Set) Parameter . . . . . . . . . . . 6 66 5. String Comparison Rules . . . . . . . . . . . . . . . . . . . 7 67 6. Encrypted JWK and Encrypted JWK Set Formats . . . . . . . . . 7 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 7.1. JSON Web Key Parameters Registry . . . . . . . . . . . . . 8 70 7.1.1. Registration Template . . . . . . . . . . . . . . . . 8 71 7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 9 72 7.2. JSON Web Key Set Parameters Registry . . . . . . . . . . . 9 73 7.2.1. Registration Template . . . . . . . . . . . . . . . . 10 74 7.2.2. Initial Registry Contents . . . . . . . . . . . . . . 10 75 7.3. JSON Web Signature and Encryption Type Values 76 Registration . . . . . . . . . . . . . . . . . . . . . . . 10 77 7.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 10 78 7.4. Media Type Registration . . . . . . . . . . . . . . . . . 10 79 7.4.1. Registry Contents . . . . . . . . . . . . . . . . . . 11 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 84 Appendix A. Example JSON Web Key Sets . . . . . . . . . . . . . . 14 85 A.1. Example Public Keys . . . . . . . . . . . . . . . . . . . 14 86 A.2. Example Private Keys . . . . . . . . . . . . . . . . . . . 15 87 A.3. Example Symmetric Keys . . . . . . . . . . . . . . . . . . 17 88 Appendix B. Example Use of "x5c" (X.509 Certificate Chain) 89 Parameter . . . . . . . . . . . . . . . . . . . . . . 17 90 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 18 91 Appendix D. Document History . . . . . . . . . . . . . . . . . . 19 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 94 1. Introduction 96 A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) [RFC4627] 97 data structure that represents a cryptographic key. This 98 specification also defines a JSON Web Key Set (JWK Set) JSON data 99 structure for representing a set of JWKs. Cryptographic algorithms 100 and identifiers for use with this specification are described in the 101 separate JSON Web Algorithms (JWA) [JWA] specification. 103 Goals for this specification do not include representing certificate 104 chains, representing certified keys, and replacing X.509 105 certificates. 107 JWKs and JWK Sets are used in the JSON Web Signature (JWS) [JWS] and 108 JSON Web Encryption (JWE) [JWE] specifications. 110 1.1. Notational Conventions 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in Key words for use in 115 RFCs to Indicate Requirement Levels [RFC2119]. 117 2. Terminology 119 JSON Web Key (JWK) A JSON object that represents a cryptographic 120 key. 122 JSON Web Key Set (JWK Set) A JSON object that contains an array of 123 JWKs as the value of its "keys" member. 125 Base64url Encoding The URL- and filename-safe Base64 encoding 126 described in RFC 4648 [RFC4648], Section 5, with the (non URL- 127 safe) '=' padding characters omitted, as permitted by Section 3.2. 128 (See Appendix C of [JWS] for notes on implementing base64url 129 encoding without padding.) 131 Collision Resistant Namespace A namespace that allows names to be 132 allocated in a manner such that they are highly unlikely to 133 collide with other names. For instance, collision resistance can 134 be achieved through administrative delegation of portions of the 135 namespace or through use of collision-resistant name allocation 136 functions. Examples of Collision Resistant Namespaces include: 137 Domain Names, Object Identifiers (OIDs) as defined in the ITU-T 138 X.660 and X.670 Recommendation series, and Universally Unique 139 IDentifiers (UUIDs) [RFC4122]. When using an administratively 140 delegated namespace, the definer of a name needs to take 141 reasonable precautions to ensure they are in control of the 142 portion of the namespace they use to define the name. 144 Encrypted JWK A JWE with a JWK as its plaintext value. 146 Encrypted JWK Set A JWE with a JWK Set as its plaintext value. 148 3. JSON Web Key (JWK) Format 150 A JSON Web Key (JWK) is a JSON object containing specific members, as 151 specified below. Those members that are common to all key types are 152 defined below. 154 In addition to the common parameters, each JWK will have members that 155 are specific to the kind of key being represented. These members 156 represent the parameters of the key. Section 5 of the JSON Web 157 Algorithms (JWA) [JWA] specification defines multiple kinds of 158 cryptographic keys and their associated members. 160 The member names within a JWK MUST be unique; receipients MUST either 161 reject JWKs with duplicate member names or use a JSON parser that 162 returns only the lexically last duplicate member name, as specified 163 in Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript]. 165 Additional members MAY be present in the JWK. If not understood by 166 implementations encountering them, they MUST be ignored. Member 167 names used for representing key parameters for different kinds of 168 keys need not be distinct. Any new member name SHOULD either be 169 registered in the IANA JSON Web Key Parameters registry Section 7.1 170 or be a value that contains a Collision Resistant Namespace. 172 3.1. "kty" (Key Type) Parameter 174 The "kty" (key type) member identifies the cryptographic algorithm 175 family used with the key. "kty" values SHOULD either be registered in 176 the IANA JSON Web Key Types registry [JWA] or be a value that 177 contains a Collision Resistant Namespace. The "kty" value is a case 178 sensitive string. Use of this member is REQUIRED. 180 A list of defined "kty" values can be found in the IANA JSON Web Key 181 Types registry [JWA]; the initial contents of this registry are the 182 values defined in Section 5.1 of the JSON Web Algorithms (JWA) [JWA] 183 specification. 185 Additional members used with these "kty" values can be found in the 186 IANA JSON Web Key Parameters registry Section 7.1; the initial 187 contents of this registry are the values defined in Sections 5.2 and 188 5.3 of the JSON Web Algorithms (JWA) [JWA] specification. 190 3.2. "use" (Key Use) Parameter 192 The "use" (key use) member identifies the intended use of the key. 193 Values defined by this specification are: 195 o "sig" (signature or MAC operation) 197 o "enc" (encryption) 199 Other values MAY be used. The "use" value is a case sensitive 200 string. Use of this member is OPTIONAL. 202 3.3. "alg" (Algorithm) Parameter 204 The "alg" (algorithm) member identifies the algorithm intended for 205 use with the key. The values used in this field are the same as 206 those used in the JWS [JWS] and JWE [JWE] "alg" and "enc" header 207 parameters; these values can be found in the JSON Web Signature and 208 Encryption Algorithms registry [JWA]. Use of this member is 209 OPTIONAL. 211 3.4. "kid" (Key ID) Parameter 213 The "kid" (key ID) member can be used to match a specific key. This 214 can be used, for instance, to choose among a set of keys within a JWK 215 Set during key rollover. The interpretation of the "kid" value is 216 unspecified. When "kid" values are used within a JWK Set, different 217 keys within the JWK Set SHOULD use distinct "kid" values. The "kid" 218 value is a case sensitive string. Use of this member is OPTIONAL. 220 When used with JWS or JWE, the "kid" value can be used to match a JWS 221 or JWE "kid" header parameter value. 223 3.5. "x5u" (X.509 URL) Header Parameter 225 The "x5u" (X.509 URL) member is a URI [RFC3986] that refers to a 226 resource for an X.509 public key certificate or certificate chain 227 [RFC5280]. The identified resource MUST provide a representation of 228 the certificate or certificate chain that conforms to RFC 5280 229 [RFC5280] in PEM encoded form [RFC1421]. The key in the first 230 certificate MUST match the bare public key represented by other 231 members of the JWK. The protocol used to acquire the resource MUST 232 provide integrity protection; an HTTP GET request to retrieve the 233 certificate MUST use TLS [RFC2818] [RFC5246]; the identity of the 234 server MUST be validated, as per Section 3.1 of HTTP Over TLS 235 [RFC2818]. Use of this member is OPTIONAL. 237 3.6. "x5t" (X.509 Certificate Thumbprint) Header Parameter 239 The "x5t" (X.509 Certificate Thumbprint) member is a base64url 240 encoded SHA-1 thumbprint (a.k.a. digest) of the DER encoding of an 241 X.509 certificate [RFC5280]. The key in the certificate MUST match 242 the bare public key represented by other members of the JWK. Use of 243 this member is OPTIONAL. 245 3.7. "x5c" (X.509 Certificate Chain) Parameter 247 The "x5c" (X.509 Certificate Chain) member contains a chain of one or 248 more PKIX certificates [RFC5280]. The certificate chain is 249 represented as a JSON array of certificate value strings. Each 250 string in the array is a base64 encoded ([RFC4648] Section 4 -- not 251 base64url encoded) DER [ITU.X690.1994] PKIX certificate value. The 252 PKIX certificate containing the key value MUST be the first 253 certificate. This MAY be followed by additional certificates, with 254 each subsequent certificate being the one used to certify the 255 previous one. The key in the first certificate MUST match the bare 256 public key represented by other members of the JWK. Use of this 257 member is OPTIONAL. 259 4. JSON Web Key Set (JWK Set) Format 261 A JSON Web Key Set (JWK Set) is a JSON object that contains an array 262 of JSON Web Key values as the value of its "keys" member. 264 The member names within a JWK Set MUST be unique; receipients MUST 265 either reject JWK Sets with duplicate member names or use a JSON 266 parser that returns only the lexically last duplicate member name, as 267 specified in Section 15.12 (The JSON Object) of ECMAScript 5.1 268 [ECMAScript]. 270 Additional members MAY be present in the JWK Set. If not understood 271 by implementations encountering them, they MUST be ignored. 272 Parameters for representing additional properties of JWK Sets SHOULD 273 either be registered in the IANA JSON Web Key Set Parameters registry 274 Section 7.2 or be a value that contains a Collision Resistant 275 Namespace. 277 4.1. "keys" (JSON Web Key Set) Parameter 279 The value of the "keys" (JSON Web Key Set) member is an array of JSON 280 Web Key (JWK) values. Use of this member is REQUIRED. 282 5. String Comparison Rules 284 Processing a JWK inevitably requires comparing known strings to 285 values in JSON objects. For example, in checking what the key type 286 is, the Unicode string encoding "kty" will be checked against the 287 member names in the JWK to see if there is a matching name. 289 Comparisons between JSON strings and other Unicode strings MUST be 290 performed by comparing Unicode code points without normalization as 291 specified in the String Comparison Rules in Section 5.3 of [JWS]. 293 6. Encrypted JWK and Encrypted JWK Set Formats 295 JWKs containing non-public key material will need to be encrypted in 296 some contexts to prevent the disclosure of private or symmetric key 297 values to unintended parties. The use of an Encrypted JWK, which is 298 a JWE with a JWK as its plaintext value, is RECOMMENED for this 299 purpose. The processing of Encrypted JWKs is identical to the 300 processing of other JWEs. A "cty" (content type) header parameter 301 value of "JWK" can be used to indicate that the content of the JWE is 302 a JWK in contexts where this is useful. 304 JWK Sets containing non-public key material will similarly need to be 305 encrypted. The use of an Encrypted JWK Set, which is a JWE with a 306 JWK Set as its plaintext value, is RECOMMENED for this purpose. The 307 processing of Encrypted JWK Sets is identical to the processing of 308 other JWEs. A "cty" (content type) header parameter value of 309 "JWK-SET" can be used to indicate that the content of the JWE is a 310 JWK Set in contexts where this is useful. 312 7. IANA Considerations 314 The following registration procedure is used for all the registries 315 established by this specification. 317 Values are registered with a Specification Required [RFC5226] after a 318 two-week review period on the [TBD]@ietf.org mailing list, on the 319 advice of one or more Designated Experts. However, to allow for the 320 allocation of values prior to publication, the Designated Expert(s) 321 may approve registration once they are satisfied that such a 322 specification will be published. 324 Registration requests must be sent to the [TBD]@ietf.org mailing list 325 for review and comment, with an appropriate subject (e.g., "Request 326 for access token type: example"). [[ Note to RFC-EDITOR: The name of 327 the mailing list should be determined in consultation with the IESG 328 and IANA. Suggested name: jose-reg-review. ]] 330 Within the review period, the Designated Expert(s) will either 331 approve or deny the registration request, communicating this decision 332 to the review list and IANA. Denials should include an explanation 333 and, if applicable, suggestions as to how to make the request 334 successful. 336 IANA must only accept registry updates from the Designated Expert(s) 337 and should direct all requests for registration to the review mailing 338 list. 340 7.1. JSON Web Key Parameters Registry 342 This specification establishes the IANA JSON Web Key Parameters 343 registry for reserved JWK parameter names. The registry records the 344 reserved parameter name and a reference to the specification that 345 defines it. It also records whether the parameter conveys public or 346 private information. This specification registers the parameter 347 names defined in Section 3. The same JWK parameter name may be 348 registered multiple times, provided that duplicate parameter 349 registrations are only for algorithm-specific JWK parameters; in this 350 case, the meaning of the duplicate parameter name is disambiguated by 351 the "kty" value of the JWK containing it. 353 7.1.1. Registration Template 355 Parameter Name: 356 The name requested (e.g., "example"). This name is case 357 sensitive. Names that match other registered names in a case 358 insensitive manner SHOULD NOT be accepted. 360 Parameter Information Class: 361 Registers whether the parameter conveys public or private 362 information. Its value must be one the words Public or Private. 364 Change Controller: 365 For Standards Track RFCs, state "IETF". For others, give the name 366 of the responsible party. Other details (e.g., postal address, 367 email address, home page URI) may also be included. 369 Specification Document(s): 370 Reference to the document(s) that specify the parameter, 371 preferably including URI(s) that can be used to retrieve copies of 372 the document(s). An indication of the relevant sections may also 373 be included but is not required. 375 7.1.2. Initial Registry Contents 377 o Parameter Name: "kty" 378 o Parameter Information Class: Public 379 o Change Controller: IETF 380 o Specification Document(s): Section 3.1 of [[ this document ]] 382 o Parameter Name: "use" 383 o Parameter Information Class: Public 384 o Change Controller: IETF 385 o Specification Document(s): Section 3.2 of [[ this document ]] 387 o Parameter Name: "alg" 388 o Parameter Information Class: Public 389 o Change Controller: IETF 390 o Specification Document(s): Section 3.3 of [[ this document ]] 392 o Parameter Name: "kid" 393 o Parameter Information Class: Public 394 o Change Controller: IETF 395 o Specification Document(s): Section 3.4 of [[ this document ]] 397 o Parameter Name: "x5u" 398 o Parameter Information Class: Public 399 o Change Controller: IETF 400 o Specification Document(s): Section 3.5 of [[ this document ]] 402 o Parameter Name: "x5t" 403 o Parameter Information Class: Public 404 o Change Controller: IETF 405 o Specification Document(s): Section 3.6 of [[ this document ]] 407 o Parameter Name: "x5c" 408 o Parameter Information Class: Public 409 o Change Controller: IETF 410 o Specification Document(s): Section 3.7 of [[ this document ]] 412 7.2. JSON Web Key Set Parameters Registry 414 This specification establishes the IANA JSON Web Key Set Parameters 415 registry for reserved JWK Set parameter names. The registry records 416 the reserved parameter name and a reference to the specification that 417 defines it. This specification registers the parameter names defined 418 in Section 4. 420 7.2.1. Registration Template 422 Parameter Name: 423 The name requested (e.g., "example"). This name is case 424 sensitive. Names that match other registered names in a case 425 insensitive manner SHOULD NOT be accepted. 427 Change Controller: 428 For Standards Track RFCs, state "IETF". For others, give the name 429 of the responsible party. Other details (e.g., postal address, 430 email address, home page URI) may also be included. 432 Specification Document(s): 433 Reference to the document(s) that specify the parameter, 434 preferably including URI(s) that can be used to retrieve copies of 435 the document(s). An indication of the relevant sections may also 436 be included but is not required. 438 7.2.2. Initial Registry Contents 440 o Parameter Name: "keys" 441 o Change Controller: IETF 442 o Specification Document(s): Section 4.1 of [[ this document ]] 444 7.3. JSON Web Signature and Encryption Type Values Registration 446 7.3.1. Registry Contents 448 This specification registers the "JWK" and "JWK-SET" type values in 449 the IANA JSON Web Signature and Encryption Type Values registry 450 [JWS], which can be used to indicate, respectively, that the content 451 is a JWK or a JWK Set. 453 o "typ" Header Parameter Value: "JWK" 454 o Abbreviation for MIME Type: application/jwk+json 455 o Change Controller: IETF 456 o Specification Document(s): Section 3 of [[ this document ]] 458 o "typ" Header Parameter Value: "JWK-SET" 459 o Abbreviation for MIME Type: application/jwk-set+json 460 o Change Controller: IETF 461 o Specification Document(s): Section 4 of [[ this document ]] 463 7.4. Media Type Registration 464 7.4.1. Registry Contents 466 This specification registers the "application/jwk+json" and 467 "application/jwk-set+json" Media Types [RFC2046] in the MIME Media 468 Type registry [RFC4288], which can be used to indicate, respectively, 469 that the content is a JWK or a JWK Set. 471 o Type Name: application 472 o Subtype Name: jwk+json 473 o Required Parameters: n/a 474 o Optional Parameters: n/a 475 o Encoding considerations: application/jwk+json values are 476 represented as JSON object; UTF-8 encoding SHOULD be employed for 477 the JSON object. 478 o Security Considerations: See the Security Considerations section 479 of [[ this document ]] 480 o Interoperability Considerations: n/a 481 o Published Specification: [[ this document ]] 482 o Applications that use this media type: TBD 483 o Additional Information: Magic number(s): n/a, File extension(s): 484 n/a, Macintosh file type code(s): n/a 485 o Person & email address to contact for further information: Michael 486 B. Jones, mbj@microsoft.com 487 o Intended Usage: COMMON 488 o Restrictions on Usage: none 489 o Author: Michael B. Jones, mbj@microsoft.com 490 o Change Controller: IETF 492 o Type Name: application 493 o Subtype Name: jwk-set+json 494 o Required Parameters: n/a 495 o Optional Parameters: n/a 496 o Encoding considerations: application/jwk-set+json values are 497 represented as a JSON Object; UTF-8 encoding SHOULD be employed 498 for the JSON object. 499 o Security Considerations: See the Security Considerations section 500 of [[ this document ]] 501 o Interoperability Considerations: n/a 502 o Published Specification: [[ this document ]] 503 o Applications that use this media type: TBD 504 o Additional Information: Magic number(s): n/a, File extension(s): 505 n/a, Macintosh file type code(s): n/a 506 o Person & email address to contact for further information: Michael 507 B. Jones, mbj@microsoft.com 508 o Intended Usage: COMMON 509 o Restrictions on Usage: none 510 o Author: Michael B. Jones, mbj@microsoft.com 511 o Change Controller: IETF 513 8. Security Considerations 515 All of the security issues faced by any cryptographic application 516 must be faced by a JWS/JWE/JWK agent. Among these issues are 517 protecting the user's private and symmetric keys, preventing various 518 attacks, and helping the user avoid mistakes such as inadvertently 519 encrypting a message for the wrong recipient. The entire list of 520 security considerations is beyond the scope of this document, but 521 some significant considerations are listed here. 523 A key is no more trustworthy than the method by which it was 524 received. 526 Private and symmetric keys must be protected from disclosure to 527 unintended parties. One recommended means of doing so is to encrypt 528 JWKs or JWK Sets containing them by using the JWK or JWK Set value as 529 the plaintext of a JWE. 531 The security considerations in RFC 3447 [RFC3447] and RFC 6030 532 [RFC6030] about protecting private and symmetric keys also apply to 533 this specification. 535 The security considerations in XML DSIG 2.0 536 [W3C.CR-xmldsig-core2-20120124], about key representations also apply 537 to this specification, other than those that are XML specific. 539 The TLS Requirements in [JWS] also apply to this specification. 541 9. References 543 9.1. Normative References 545 [ECMAScript] 546 Ecma International, "ECMAScript Language Specification, 547 5.1 Edition", ECMA 262, June 2011. 549 [ITU.X690.1994] 550 International Telecommunications Union, "Information 551 Technology - ASN.1 encoding rules: Specification of Basic 552 Encoding Rules (BER), Canonical Encoding Rules (CER) and 553 Distinguished Encoding Rules (DER)", ITU-T Recommendation 554 X.690, 1994. 556 [JWA] Jones, M., "JSON Web Algorithms (JWA)", 557 draft-ietf-jose-json-web-algorithms (work in progress), 558 July 2013. 560 [JWE] Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web 561 Encryption (JWE)", draft-ietf-jose-json-web-encryption 562 (work in progress), July 2013. 564 [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 565 Signature (JWS)", draft-ietf-jose-json-web-signature (work 566 in progress), July 2013. 568 [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic 569 Mail: Part I: Message Encryption and Authentication 570 Procedures", RFC 1421, February 1993. 572 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 573 Extensions (MIME) Part Two: Media Types", RFC 2046, 574 November 1996. 576 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 577 Requirement Levels", BCP 14, RFC 2119, March 1997. 579 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 581 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 582 Resource Identifier (URI): Generic Syntax", STD 66, 583 RFC 3986, January 2005. 585 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 586 Registration Procedures", RFC 4288, December 2005. 588 [RFC4627] Crockford, D., "The application/json Media Type for 589 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 591 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 592 Encodings", RFC 4648, October 2006. 594 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 595 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 596 May 2008. 598 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 599 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 601 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 602 Housley, R., and W. Polk, "Internet X.509 Public Key 603 Infrastructure Certificate and Certificate Revocation List 604 (CRL) Profile", RFC 5280, May 2008. 606 [W3C.CR-xmldsig-core2-20120124] 607 Eastlake, D., Reagle, J., Yiu, K., Solo, D., Datta, P., 608 Hirsch, F., Cantor, S., and T. Roessler, "XML Signature 609 Syntax and Processing Version 2.0", World Wide Web 610 Consortium CR CR-xmldsig-core2-20120124, January 2012, 611 . 613 9.2. Informative References 615 [MagicSignatures] 616 Panzer (editor), J., Laurie, B., and D. Balfanz, "Magic 617 Signatures", January 2011. 619 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 620 Standards (PKCS) #1: RSA Cryptography Specifications 621 Version 2.1", RFC 3447, February 2003. 623 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 624 Unique IDentifier (UUID) URN Namespace", RFC 4122, 625 July 2005. 627 [RFC6030] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric 628 Key Container (PSKC)", RFC 6030, October 2010. 630 Appendix A. Example JSON Web Key Sets 632 A.1. Example Public Keys 634 The following example JWK Set contains two public keys represented as 635 JWKs: one using an Elliptic Curve algorithm and a second one using an 636 RSA algorithm. The first specifies that the key is to be used for 637 encryption. The second specifies that the key is to be used with the 638 "RS256" algorithm. Both provide a Key ID for key matching purposes. 639 In both cases, integers are represented using the base64url encoding 640 of their big endian representations. (Long lines are broken are for 641 display purposes only.) 642 {"keys": 643 [ 644 {"kty":"EC", 645 "crv":"P-256", 646 "x":"MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4", 647 "y":"4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM", 648 "use":"enc", 649 "kid":"1"}, 651 {"kty":"RSA", 652 "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx 653 4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs 654 tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2 655 QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI 656 SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb 657 w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw", 658 "e":"AQAB", 659 "alg":"RS256", 660 "kid":"2011-04-29"} 661 ] 662 } 664 A.2. Example Private Keys 666 The following example JWK Set contains two keys represented as JWKs 667 containing both public and private key values: one using an Elliptic 668 Curve algorithm and a second one using an RSA algorithm. This 669 example extends the example in the previous section, adding private 670 key values. (Line breaks are for display purposes only.) 671 {"keys": 672 [ 673 {"kty":"EC", 674 "crv":"P-256", 675 "x":"MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4", 676 "y":"4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM", 677 "d":"870MB6gfuTJ4HtUnUvYMyJpr5eUZNP4Bk43bVdj3eAE", 678 "use":"enc", 679 "kid":"1"}, 681 {"kty":"RSA", 682 "n":"0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx4 683 cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMst 684 n64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2Q 685 vzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbIS 686 D08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqbw 687 0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw", 688 "e":"AQAB", 689 "d":"X4cTteJY_gn4FYPsXB8rdXix5vwsg1FLN5E3EaG6RJoVH-HLLKD9 690 M7dx5oo7GURknchnrRweUkC7hT5fJLM0WbFAKNLWY2vv7B6NqXSzUvxT0_YSfqij 691 wp3RTzlBaCxWp4doFk5N2o8Gy_nHNKroADIkJ46pRUohsXywbReAdYaMwFs9tv8d 692 _cPVY3i07a3t8MN6TNwm0dSawm9v47UiCl3Sk5ZiG7xojPLu4sbg1U2jx4IBTNBz 693 nbJSzFHK66jT8bgkuqsk0GjskDJk19Z4qwjwbsnn4j2WBii3RL-Us2lGVkY8fkFz 694 me1z0HbIkfz0Y6mqnOYtqc0X4jfcKoAC8Q", 695 "p":"83i-7IvMGXoMXCskv73TKr8637FiO7Z27zv8oj6pbWUQyLPQBQxtPV 696 nwD20R-60eTDmD2ujnMt5PoqMrm8RfmNhVWDtjjMmCMjOpSXicFHj7XOuVIYQyqV 697 WlWEh6dN36GVZYk93N8Bc9vY41xy8B9RzzOGVQzXvNEvn7O0nVbfs", 698 "q":"3dfOR9cuYq-0S-mkFLzgItgMEfFzB2q3hWehMuG0oCuqnb3vobLyum 699 qjVZQO1dIrdwgTnCdpYzBcOfW5r370AFXjiWft_NGEiovonizhKpo9VVS78TzFgx 700 kIdrecRezsZ-1kYd_s1qDbxtkDEgfAITAG9LUnADun4vIcb6yelxk", 701 "dp":"G4sPXkc6Ya9y8oJW9_ILj4xuppu0lzi_H7VTkS8xj5SdX3coE0oim 702 YwxIi2emTAue0UOa5dpgFGyBJ4c8tQ2VF402XRugKDTP8akYhFo5tAA77Qe_Nmtu 703 YZc3C3m3I24G2GvR5sSDxUyAN2zq8Lfn9EUms6rY3Ob8YeiKkTiBj0", 704 "dq":"s9lAH9fggBsoFR8Oac2R_E2gw282rT2kGOAhvIllETE1efrA6huUU 705 vMfBcMpn8lqeW6vzznYY5SSQF7pMdC_agI3nG8Ibp1BUb0JUiraRNqUfLhcQb_d9 706 GF4Dh7e74WbRsobRonujTYN1xCaP6TO61jvWrX-L18txXw494Q_cgk", 707 "qi":"GyM_p6JrXySiz1toFgKbWV-JdI3jQ4ypu9rbMWx3rQJBfmt0FoYzg 708 UIZEVFEcOqwemRN81zoDAaa-Bk0KWNGDjJHZDdDmFhW3AN7lI-puxk_mHZGJ11rx 709 yR8O55XLSe3SPmRfKwZI6yU24ZxvQKFYItdldUKGzO6Ia6zTKhAVRU", 710 "alg":"RS256", 711 "kid":"2011-04-29"} 712 ] 713 } 715 A.3. Example Symmetric Keys 717 The following example JWK Set contains two symmetric keys represented 718 as JWKs: one designated as being for use with the AES Key Wrap 719 algorithm and a second one that is an HMAC key. (Line breaks are for 720 display purposes only.) 722 {"keys": 723 [ 724 {"kty":"oct", 725 "alg":"A128KW", 726 "k":"GawgguFyGrWKav7AX4VKUg"}, 728 {"kty":"oct", 729 "k":"AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75 730 aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow", 731 "kid":"HMAC key used in JWS A.1 example"} 732 ] 733 } 735 Appendix B. Example Use of "x5c" (X.509 Certificate Chain) Parameter 736 The following is a non-normative example of a JWK with a RSA signing 737 key represented both as a bare public key and as an X.509 certificate 738 using the "x5c" parameter: 740 {"kty":"RSA", 741 "use":"sig", 742 "kid":"1b94c", 743 "n":"vrjOfz9Ccdgx5nQudyhdoR17V-IubWMeOZCwX_jj0hgAsz2J_pqYW08 744 PLbK_PdiVGKPrqzmDIsLI7sA25VEnHU1uCLNwBuUiCO11_-7dYbsr4iJmG0Q 745 u2j8DsVyT1azpJC_NG84Ty5KKthuCaPod7iI7w0LK9orSMhBEwwZDCxTWq4a 746 YWAchc8t-emd9qOvWtVMDC2BXksRngh6X5bUYLy6AyHKvj-nUy1wgzjYQDwH 747 MTplCoLtU-o-8SNnZ1tmRoGE9uJkBLdh5gFENabWnU5m1ZqZPdwS-qo-meMv 748 VfJb6jJVWRpl2SUtCnYG2C32qvbWbjZ_jBPD5eunqsIo1vQ", 749 "e":"AQAB", 750 "x5c": 751 ["MIIDQjCCAiqgAwIBAgIGATz/FuLiMA0GCSqGSIb3DQEBBQUAMGIxCzAJB 752 gNVBAYTAlVTMQswCQYDVQQIEwJDTzEPMA0GA1UEBxMGRGVudmVyMRwwGgYD 753 VQQKExNQaW5nIElkZW50aXR5IENvcnAuMRcwFQYDVQQDEw5CcmlhbiBDYW1 754 wYmVsbDAeFw0xMzAyMjEyMzI5MTVaFw0xODA4MTQyMjI5MTVaMGIxCzAJBg 755 NVBAYTAlVTMQswCQYDVQQIEwJDTzEPMA0GA1UEBxMGRGVudmVyMRwwGgYDV 756 QQKExNQaW5nIElkZW50aXR5IENvcnAuMRcwFQYDVQQDEw5CcmlhbiBDYW1w 757 YmVsbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL64zn8/QnH 758 YMeZ0LncoXaEde1fiLm1jHjmQsF/449IYALM9if6amFtPDy2yvz3YlRij66 759 s5gyLCyO7ANuVRJx1NbgizcAblIgjtdf/u3WG7K+IiZhtELto/A7Fck9Ws6 760 SQvzRvOE8uSirYbgmj6He4iO8NCyvaK0jIQRMMGQwsU1quGmFgHIXPLfnpn 761 fajr1rVTAwtgV5LEZ4Iel+W1GC8ugMhyr4/p1MtcIM42EA8BzE6ZQqC7VPq 762 PvEjZ2dbZkaBhPbiZAS3YeYBRDWm1p1OZtWamT3cEvqqPpnjL1XyW+oyVVk 763 aZdklLQp2Btgt9qr21m42f4wTw+Xrp6rCKNb0CAwEAATANBgkqhkiG9w0BA 764 QUFAAOCAQEAh8zGlfSlcI0o3rYDPBB07aXNswb4ECNIKG0CETTUxmXl9KUL 765 +9gGlqCz5iWLOgWsnrcKcY0vXPG9J1r9AqBNTqNgHq2G03X09266X5CpOe1 766 zFo+Owb1zxtp3PehFdfQJ610CDLEaS9V9Rqp17hCyybEpOGVwe8fnk+fbEL 767 2Bo3UPGrpsHzUoaGpDftmWssZkhpBJKVMJyf/RuP2SmmaIzmnw9JiSlYhzo 768 4tpzd5rFXhjRbg4zW9C+2qok+2+qDM1iJ684gPHMIY8aLWrdgQTxkumGmTq 769 gawR+N5MDtdPTEQ0XfIBc2cJEUyMTY5MPvACWpkA6SdS4xSvdXK3IVfOWA=="] 770 } 772 Appendix C. Acknowledgements 774 A JSON representation for RSA public keys was previously introduced 775 by John Panzer, Ben Laurie, and Dirk Balfanz in Magic Signatures 776 [MagicSignatures]. 778 This specification is the work of the JOSE Working Group, which 779 includes dozens of active and dedicated participants. In particular, 780 the following individuals contributed ideas, feedback, and wording 781 that influenced this specification: 783 Dirk Balfanz, Richard Barnes, John Bradley, Brian Campbell, Breno de 784 Medeiros, Joe Hildebrand, Edmund Jay, Ben Laurie, James Manger, Matt 785 Miller, Tony Nadalin, Axel Nennker, John Panzer, Eric Rescorla, Nat 786 Sakimura, Jim Schaad, Paul Tarjan, Hannes Tschofenig, and Sean 787 Turner. 789 Jim Schaad and Karen O'Donoghue chaired the JOSE working group and 790 Sean Turner and Stephen Farrell served as Security area directors 791 during the creation of this specification. 793 Appendix D. Document History 795 [[ to be removed by the RFC editor before publication as an RFC ]] 797 -12 799 o Stated that receipients MUST either reject JWKs and JWK Sets with 800 duplicate member names or use a JSON parser that returns only the 801 lexically last duplicate member name. 803 -11 805 o Stated that when "kid" values are used within a JWK Set, different 806 keys within the JWK Set SHOULD use distinct "kid" values. 808 o Added optional "x5u" (X.509 URL), "x5t" (X.509 Certificate 809 Thumbprint), and "x5c" (X.509 Certificate Chain) JWK parameters. 811 o Added section on Encrypted JWK and Encrypted JWK Set Formats. 813 o Added a Parameter Information Class value to the JSON Web Key 814 Parameters registry, which registers whether the parameter conveys 815 public or private information. 817 o Registered "application/jwk+json" and "application/jwk-set+json" 818 MIME types and "JWK" and "JWK-SET" typ header parameter values, 819 addressing issue #21. 821 -10 823 o No changes were made, other than to the version number and date. 825 -09 827 o Expanded the scope of the JWK specification to include private and 828 symmetric key representations, as specified by 829 draft-jones-jose-json-private-and-symmetric-key-00. 831 o Defined that members that are not understood must be ignored. 833 -08 835 o Changed the name of the JWK key type parameter from "alg" to "kty" 836 to enable use of "alg" to indicate the particular algorithm that 837 the key is intended to be used with. 839 o Clarified statements of the form "This member is OPTIONAL" to "Use 840 of this member is OPTIONAL". 842 o Referenced String Comparison Rules in JWS. 844 o Added seriesInfo information to Internet Draft references. 846 -07 848 o Changed the name of the JWK RSA modulus parameter from "mod" to 849 "n" and the name of the JWK RSA exponent parameter from "xpo" to 850 "e", so that the identifiers are the same as those used in RFC 851 3447. 853 -06 855 o Changed the name of the JWK RSA exponent parameter from "exp" to 856 "xpo" so as to allow the potential use of the name "exp" for a 857 future extension that might define an expiration parameter for 858 keys. (The "exp" name is already used for this purpose in the JWT 859 specification.) 861 o Clarify that the "alg" (algorithm family) member is REQUIRED. 863 o Correct an instance of "JWK" that should have been "JWK Set". 865 o Applied changes made by the RFC Editor to RFC 6749's registry 866 language to this specification. 868 -05 870 o Indented artwork elements to better distinguish them from the body 871 text. 873 -04 875 o Refer to the registries as the primary sources of defined values 876 and then secondarily reference the sections defining the initial 877 contents of the registries. 879 o Normatively reference XML DSIG 2.0 [W3C.CR-xmldsig-core2-20120124] 880 for its security considerations. 882 o Added this language to Registration Templates: "This name is case 883 sensitive. Names that match other registered names in a case 884 insensitive manner SHOULD NOT be accepted." 886 o Described additional open issues. 888 o Applied editorial suggestions. 890 -03 892 o Clarified that "kid" values need not be unique within a JWK Set. 894 o Moved JSON Web Key Parameters registry to the JWK specification. 896 o Added "Collision Resistant Namespace" to the terminology section. 898 o Changed registration requirements from RFC Required to 899 Specification Required with Expert Review. 901 o Added Registration Template sections for defined registries. 903 o Added Registry Contents sections to populate registry values. 905 o Numerous editorial improvements. 907 -02 909 o Simplified JWK terminology to get replace the "JWK Key Object" and 910 "JWK Container Object" terms with simply "JSON Web Key (JWK)" and 911 "JSON Web Key Set (JWK Set)" and to eliminate potential confusion 912 between single keys and sets of keys. As part of this change, the 913 top-level member name for a set of keys was changed from "jwk" to 914 "keys". 916 o Clarified that values with duplicate member names MUST be 917 rejected. 919 o Established JSON Web Key Set Parameters registry. 921 o Explicitly listed non-goals in the introduction. 923 o Moved algorithm-specific definitions from JWK to JWA. 925 o Reformatted to give each member definition its own section 926 heading. 928 -01 930 o Corrected the Magic Signatures reference. 932 -00 934 o Created the initial IETF draft based upon 935 draft-jones-json-web-key-03 with no normative changes. 937 Author's Address 939 Michael B. Jones 940 Microsoft 942 Email: mbj@microsoft.com 943 URI: http://self-issued.info/