idnits 2.17.1 draft-ietf-jose-json-web-algorithms-03.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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2012) is 4312 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. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS' -- Possible downref: Non-RFC (?) normative reference: ref. 'JWE' -- Possible downref: Non-RFC (?) normative reference: ref. 'JWK' -- Possible downref: Non-RFC (?) normative reference: ref. 'JWS' ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 3394 ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 6090 -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' -- Possible downref: Non-RFC (?) normative reference: ref. 'USASCII' Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 8 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 6, 2012 5 Expires: January 7, 2013 7 JSON Web Algorithms (JWA) 8 draft-ietf-jose-json-web-algorithms-03 10 Abstract 12 The JSON Web Algorithms (JWA) specification enumerates cryptographic 13 algorithms and identifiers to be used with the JSON Web Signature 14 (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) 15 specifications. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 7, 2013. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. Terms Incorporated from the JWS Specification . . . . . . 4 55 2.2. Terms Incorporated from the JWE Specification . . . . . . 5 56 2.3. Terms Incorporated from the JWK Specification . . . . . . 6 57 2.4. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 7 58 3. Cryptographic Algorithms for JWS . . . . . . . . . . . . . . . 7 59 3.1. "alg" (Algorithm) Header Parameter Values for JWS . . . . 7 60 3.2. MAC with HMAC SHA-256, HMAC SHA-384, or HMAC SHA-512 . . . 8 61 3.3. Digital Signature with RSA SHA-256, RSA SHA-384, or 62 RSA SHA-512 . . . . . . . . . . . . . . . . . . . . . . . 9 63 3.4. Digital Signature with ECDSA P-256 SHA-256, ECDSA 64 P-384 SHA-384, or ECDSA P-521 SHA-512 . . . . . . . . . . 10 65 3.5. Using the Algorithm "none" . . . . . . . . . . . . . . . . 11 66 3.6. Additional Digital Signature/MAC Algorithms and 67 Parameters . . . . . . . . . . . . . . . . . . . . . . . . 12 68 4. Cryptographic Algorithms for JWE . . . . . . . . . . . . . . . 12 69 4.1. "alg" (Algorithm) Header Parameter Values for JWE . . . . 12 70 4.2. "enc" (Encryption Method) Header Parameter Values for 71 JWE . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 4.3. "int" (Integrity Algorithm) Header Parameter Values 73 for JWE . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 4.4. "kdf" (Key Derivation Function) Header Parameter 75 Values for JWE . . . . . . . . . . . . . . . . . . . . . . 14 76 4.5. Key Encryption with RSAES-PKCS1-V1_5 . . . . . . . . . . . 15 77 4.6. Key Encryption with RSAES OAEP . . . . . . . . . . . . . . 15 78 4.7. Key Agreement with Elliptic Curve Diffie-Hellman 79 Ephemeral Static (ECDH-ES) . . . . . . . . . . . . . . . . 15 80 4.8. Key Encryption with AES Key Wrap . . . . . . . . . . . . . 15 81 4.9. Plaintext Encryption with AES CBC Mode . . . . . . . . . . 15 82 4.10. Plaintext Encryption with AES GCM . . . . . . . . . . . . 16 83 4.11. Integrity Calculation with HMAC SHA-256, HMAC SHA-384, 84 or HMAC SHA-512 . . . . . . . . . . . . . . . . . . . . . 16 85 4.12. Key Derivation with Concat KDF and SHA-256, SHA-384, 86 or SHA-512 . . . . . . . . . . . . . . . . . . . . . . . . 16 87 4.13. Additional Encryption Algorithms and Parameters . . . . . 17 88 5. Cryptographic Algorithms for JWK . . . . . . . . . . . . . . . 18 89 5.1. "alg" (Algorithm Family) Parameter Values for JWK . . . . 18 90 5.2. JWK Parameters for Elliptic Curve Keys . . . . . . . . . . 18 91 5.2.1. "crv" (Curve) Parameter . . . . . . . . . . . . . . . 18 92 5.2.2. "x" (X Coordinate) Parameter . . . . . . . . . . . . . 19 93 5.2.3. "y" (Y Coordinate) Parameter . . . . . . . . . . . . . 19 94 5.3. JWK Parameters for RSA Keys . . . . . . . . . . . . . . . 19 95 5.3.1. "mod" (Modulus) Parameter . . . . . . . . . . . . . . 19 96 5.3.2. "exp" (Exponent) Parameter . . . . . . . . . . . . . . 19 98 5.4. Additional Key Algorithm Families and Parameters . . . . . 19 99 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 100 6.1. JSON Web Signature and Encryption Algorithms Registry . . 20 101 6.1.1. Registration Template . . . . . . . . . . . . . . . . 21 102 6.1.2. Initial Registry Contents . . . . . . . . . . . . . . 21 103 6.2. JSON Web Key Algorithm Families Registry . . . . . . . . . 26 104 6.2.1. Registration Template . . . . . . . . . . . . . . . . 26 105 6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 27 106 6.3. JSON Web Key Parameters Registration . . . . . . . . . . . 27 107 6.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 27 108 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 109 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 29 110 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 111 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 112 9.2. Informative References . . . . . . . . . . . . . . . . . . 31 113 Appendix A. Digital Signature/MAC Algorithm Identifier 114 Cross-Reference . . . . . . . . . . . . . . . . . . . 32 115 Appendix B. Encryption Algorithm Identifier Cross-Reference . . . 34 116 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 36 117 Appendix D. Document History . . . . . . . . . . . . . . . . . . 36 118 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39 120 1. Introduction 122 The JSON Web Algorithms (JWA) specification enumerates cryptographic 123 algorithms and identifiers to be used with the JSON Web Signature 124 (JWS) [JWS], JSON Web Encryption (JWE) [JWE], and JSON Web Key (JWK) 125 [JWK] specifications. This specification also describes the 126 semantics and operations that are specific to these algorithms and 127 algorithm families. 129 Enumerating the algorithms and identifiers for them in this 130 specification, rather than in the JWS, JWE, and JWK specifications, 131 is intended to allow them to remain unchanged in the face of changes 132 in the set of required, recommended, optional, and deprecated 133 algorithms over time. 135 1.1. Notational Conventions 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in Key words for use in 140 RFCs to Indicate Requirement Levels [RFC2119]. 142 2. Terminology 144 2.1. Terms Incorporated from the JWS Specification 146 These terms defined by the JSON Web Signature (JWS) [JWS] 147 specification are incorporated into this specification: 149 JSON Web Signature (JWS) A data structure cryptographically securing 150 a JWS Header and a JWS Payload with a JWS Signature value. 152 JWS Header A string representing a JavaScript Object Notation (JSON) 153 [RFC4627] object that describes the digital signature or MAC 154 operation applied to create the JWS Signature value. 156 JWS Payload The bytes to be secured - a.k.a., the message. The 157 payload can contain an arbitrary sequence of bytes. 159 JWS Signature A byte array containing the cryptographic material 160 that secures the contents of the JWS Header and the JWS Payload. 162 Encoded JWS Header Base64url encoding of the bytes of the UTF-8 163 [RFC3629] representation of the JWS Header. 165 Encoded JWS Payload Base64url encoding of the JWS Payload. 167 Encoded JWS Signature Base64url encoding of the JWS Signature. 169 JWS Secured Input The concatenation of the Encoded JWS Header, a 170 period ('.') character, and the Encoded JWS Payload. 172 Base64url Encoding For the purposes of this specification, this term 173 always refers to the URL- and filename-safe Base64 encoding 174 described in RFC 4648 [RFC4648], Section 5, with the (non URL- 175 safe) '=' padding characters omitted, as permitted by Section 3.2. 176 (See Appendix C of [JWS] for notes on implementing base64url 177 encoding without padding.) 179 Collision Resistant Namespace A namespace that allows names to be 180 allocated in a manner such that they are highly unlikely to 181 collide with other names. For instance, collision resistance can 182 be achieved through administrative delegation of portions of the 183 namespace or through use of collision-resistant name allocation 184 functions. Examples of Collision Resistant Namespaces include: 185 Domain Names, Object Identifiers (OIDs) as defined in the ITU-T 186 X.660 and X.670 Recommendation series, and Universally Unique 187 IDentifiers (UUIDs) [RFC4122]. When using an administratively 188 delegated namespace, the definer of a name needs to take 189 reasonable precautions to ensure they are in control of the 190 portion of the namespace they use to define the name. 192 2.2. Terms Incorporated from the JWE Specification 194 These terms defined by the JSON Web Encryption (JWE) [JWE] 195 specification are incorporated into this specification: 197 JSON Web Encryption (JWE) A data structure representing an encrypted 198 version of a Plaintext. The structure consists of four parts: the 199 JWE Header, the JWE Encrypted Key, the JWE Ciphertext, and the JWE 200 Integrity Value. 202 Plaintext The bytes to be encrypted - a.k.a., the message. The 203 plaintext can contain an arbitrary sequence of bytes. 205 Ciphertext The encrypted version of the Plaintext. 207 Content Encryption Key (CEK) A symmetric key used to encrypt the 208 Plaintext for the recipient to produce the Ciphertext. 210 Content Integrity Key (CIK) A key used with a MAC function to ensure 211 the integrity of the Ciphertext and the parameters used to create 212 it. 214 Content Master Key (CMK) A key from which the CEK and CIK are 215 derived. When key wrapping or key encryption are employed, the 216 CMK is randomly generated and encrypted to the recipient as the 217 JWE Encrypted Key. When key agreement is employed, the CMK is the 218 result of the key agreement algorithm. 220 JWE Header A string representing a JSON object that describes the 221 encryption operations applied to create the JWE Encrypted Key, the 222 JWE Ciphertext, and the JWE Integrity Value. 224 JWE Encrypted Key When key wrapping or key encryption are employed, 225 the Content Master Key (CMK) is encrypted with the intended 226 recipient's key and the resulting encrypted content is recorded as 227 a byte array, which is referred to as the JWE Encrypted Key. 228 Otherwise, when key agreement is employed, the JWE Encrypted Key 229 is the empty byte array. 231 JWE Ciphertext A byte array containing the Ciphertext. 233 JWE Integrity Value A byte array containing a MAC value that ensures 234 the integrity of the Ciphertext and the parameters used to create 235 it. 237 Encoded JWE Header Base64url encoding of the bytes of the UTF-8 238 [RFC3629] representation of the JWE Header. 240 Encoded JWE Encrypted Key Base64url encoding of the JWE Encrypted 241 Key. 243 Encoded JWE Ciphertext Base64url encoding of the JWE Ciphertext. 245 Encoded JWE Integrity Value Base64url encoding of the JWE Integrity 246 Value. 248 AEAD Algorithm An Authenticated Encryption with Associated Data 249 (AEAD) [RFC5116] encryption algorithm is one that provides an 250 integrated content integrity check. AES Galois/Counter Mode (GCM) 251 is one such algorithm. 253 2.3. Terms Incorporated from the JWK Specification 255 These terms defined by the JSON Web Key (JWK) [JWK] specification are 256 incorporated into this specification: 258 JSON Web Key (JWK) A JSON data structure that represents a public 259 key. 261 JSON Web Key Set (JWK Set) A JSON object that contains an array of 262 JWKs as a member. 264 2.4. Defined Terms 266 These terms are defined for use by this specification: 268 Header Parameter Name The name of a member of the JSON object 269 representing a JWS Header or JWE Header. 271 Header Parameter Value The value of a member of the JSON object 272 representing a JWS Header or JWE Header. 274 3. Cryptographic Algorithms for JWS 276 JWS uses cryptographic algorithms to digitally sign or create a 277 Message Authentication Codes (MAC) of the contents of the JWS Header 278 and the JWS Payload. The use of the following algorithms for 279 producing JWSs is defined in this section. 281 3.1. "alg" (Algorithm) Header Parameter Values for JWS 283 The table below is the set of "alg" (algorithm) header parameter 284 values defined by this specification for use with JWS, each of which 285 is explained in more detail in the following sections: 287 +--------------+--------------------------------+-------------------+ 288 | alg | Digital Signature or MAC | Implementation | 289 | Parameter | Algorithm | Requirements | 290 | Value | | | 291 +--------------+--------------------------------+-------------------+ 292 | HS256 | HMAC using SHA-256 hash | REQUIRED | 293 | | algorithm | | 294 | HS384 | HMAC using SHA-384 hash | OPTIONAL | 295 | | algorithm | | 296 | HS512 | HMAC using SHA-512 hash | OPTIONAL | 297 | | algorithm | | 298 | RS256 | RSASSA using SHA-256 hash | RECOMMENDED | 299 | | algorithm | | 300 | RS384 | RSASSA using SHA-384 hash | OPTIONAL | 301 | | algorithm | | 302 | RS512 | RSASSA using SHA-512 hash | OPTIONAL | 303 | | algorithm | | 304 | ES256 | ECDSA using P-256 curve and | RECOMMENDED+ | 305 | | SHA-256 hash algorithm | | 306 | ES384 | ECDSA using P-384 curve and | OPTIONAL | 307 | | SHA-384 hash algorithm | | 308 | ES512 | ECDSA using P-521 curve and | OPTIONAL | 309 | | SHA-512 hash algorithm | | 310 | none | No digital signature or MAC | REQUIRED | 311 | | value included | | 312 +--------------+--------------------------------+-------------------+ 314 All the names are short because a core goal of JWS is for the 315 representations to be compact. However, there is no a priori length 316 restriction on "alg" values. 318 The use of "+" in the Implementation Requirements indicates that the 319 requirement strength is likely to be increased in a future version of 320 the specification. 322 See Appendix A for a table cross-referencing the digital signature 323 and MAC "alg" (algorithm) values used in this specification with the 324 equivalent identifiers used by other standards and software packages. 326 3.2. MAC with HMAC SHA-256, HMAC SHA-384, or HMAC SHA-512 328 Hash-based Message Authentication Codes (HMACs) enable one to use a 329 secret plus a cryptographic hash function to generate a Message 330 Authentication Code (MAC). This can be used to demonstrate that the 331 MAC matches the hashed content, in this case the JWS Secured Input, 332 which therefore demonstrates that whoever generated the MAC was in 333 possession of the secret. The means of exchanging the shared key is 334 outside the scope of this specification. 336 The algorithm for implementing and validating HMACs is provided in 337 RFC 2104 [RFC2104]. This section defines the use of the HMAC SHA- 338 256, HMAC SHA-384, and HMAC SHA-512 functions [SHS]. The "alg" 339 (algorithm) header parameter values "HS256", "HS384", and "HS512" are 340 used in the JWS Header to indicate that the Encoded JWS Signature 341 contains a base64url encoded HMAC value using the respective hash 342 function. 344 A key of the same size as the hash output (for instance, 256 bits for 345 "HS256") or larger MUST be used with this algorithm. 347 The HMAC SHA-256 MAC is generated per RFC 2104, using SHA-256 as the 348 hash algorithm "H", using the bytes of the ASCII [USASCII] 349 representation of the JWS Secured Input as the "text" value, and 350 using the shared key. The HMAC output value is the JWS Signature. 351 The JWS signature is base64url encoded to produce the Encoded JWS 352 Signature. 354 The HMAC SHA-256 MAC for a JWS is validated by computing an HMAC 355 value per RFC 2104, using SHA-256 as the hash algorithm "H", using 356 the bytes of the ASCII representation of the received JWS Secured 357 input as the "text" value, and using the shared key. This computed 358 HMAC value is then compared to the result of base64url decoding the 359 received Encoded JWS signature. Alternatively, the computed HMAC 360 value can be base64url encoded and compared to the received Encoded 361 JWS Signature, as this comparison produces the same result as 362 comparing the unencoded values. In either case, if the values match, 363 the HMAC has been validated. If the validation fails, the JWS MUST 364 be rejected. 366 Securing content with the HMAC SHA-384 and HMAC SHA-512 algorithms is 367 performed identically to the procedure for HMAC SHA-256 - just using 368 the corresponding hash algorithm with correspondingly larger minimum 369 key sizes and result values: 384 bits each for HMAC SHA-384 and 512 370 bits each for HMAC SHA-512. 372 3.3. Digital Signature with RSA SHA-256, RSA SHA-384, or RSA SHA-512 374 This section defines the use of the RSASSA-PKCS1-V1_5 digital 375 signature algorithm as defined in Section 8.2 of RFC 3447 [RFC3447], 376 (commonly known as PKCS #1), using SHA-256, SHA-384, or SHA-512 [SHS] 377 as the hash functions. The "alg" (algorithm) header parameter values 378 "RS256", "RS384", and "RS512" are used in the JWS Header to indicate 379 that the Encoded JWS Signature contains a base64url encoded RSA 380 digital signature using the respective hash function. 382 A key of size 2048 bits or larger MUST be used with these algorithms. 384 The RSA SHA-256 digital signature is generated as follows: 386 1. Generate a digital signature of the bytes of the ASCII 387 representation of the JWS Secured Input using RSASSA-PKCS1-V1_5- 388 SIGN and the SHA-256 hash function with the desired private key. 389 The output will be a byte array. 391 2. Base64url encode the resulting byte array. 393 The output is the Encoded JWS Signature for that JWS. 395 The RSA SHA-256 digital signature for a JWS is validated as follows: 397 1. Take the Encoded JWS Signature and base64url decode it into a 398 byte array. If decoding fails, the JWS MUST be rejected. 400 2. Submit the bytes of the ASCII representation of the JWS Secured 401 Input and the public key corresponding to the private key used by 402 the signer to the RSASSA-PKCS1-V1_5-VERIFY algorithm using SHA- 403 256 as the hash function. 405 3. If the validation fails, the JWS MUST be rejected. 407 Signing with the RSA SHA-384 and RSA SHA-512 algorithms is performed 408 identically to the procedure for RSA SHA-256 - just using the 409 corresponding hash algorithm with correspondingly larger result 410 values: 384 bits for RSA SHA-384 and 512 bits for RSA SHA-512. 412 3.4. Digital Signature with ECDSA P-256 SHA-256, ECDSA P-384 SHA-384, 413 or ECDSA P-521 SHA-512 415 The Elliptic Curve Digital Signature Algorithm (ECDSA) [DSS] provides 416 for the use of Elliptic Curve cryptography, which is able to provide 417 equivalent security to RSA cryptography but using shorter key sizes 418 and with greater processing speed. This means that ECDSA digital 419 signatures will be substantially smaller in terms of length than 420 equivalently strong RSA digital signatures. 422 This specification defines the use of ECDSA with the P-256 curve and 423 the SHA-256 cryptographic hash function, ECDSA with the P-384 curve 424 and the SHA-384 hash function, and ECDSA with the P-521 curve and the 425 SHA-512 hash function. The P-256, P-384, and P-521 curves are 426 defined in [DSS]. The "alg" (algorithm) header parameter values 427 "ES256", "ES384", and "ES512" are used in the JWS Header to indicate 428 that the Encoded JWS Signature contains a base64url encoded ECDSA 429 P-256 SHA-256, ECDSA P-384 SHA-384, or ECDSA P-521 SHA-512 digital 430 signature, respectively. 432 The ECDSA P-256 SHA-256 digital signature is generated as follows: 434 1. Generate a digital signature of the bytes of the ASCII 435 representation of the JWS Secured Input using ECDSA P-256 SHA-256 436 with the desired private key. The output will be the EC point 437 (R, S), where R and S are unsigned integers. 439 2. Turn R and S into byte arrays in big endian order, with each 440 array being be 32 bytes long. 442 3. Concatenate the two byte arrays in the order R and then S. (Note 443 that many ECDSA implementations will directly produce this 444 concatenation as their output.) 446 4. Base64url encode the resulting 64 byte array. 448 The output is the Encoded JWS Signature for the JWS. 450 The ECDSA P-256 SHA-256 digital signature for a JWS is validated as 451 follows: 453 1. Take the Encoded JWS Signature and base64url decode it into a 454 byte array. If decoding fails, the JWS MUST be rejected. 456 2. The output of the base64url decoding MUST be a 64 byte array. If 457 decoding does not result in a 64 byte array, the JWS MUST be 458 rejected. 460 3. Split the 64 byte array into two 32 byte arrays. The first array 461 will be R and the second S (with both being in big endian byte 462 order). 464 4. Submit the bytes of the ASCII representation of the JWS Secured 465 Input R, S and the public key (x, y) to the ECDSA P-256 SHA-256 466 validator. 468 5. If the validation fails, the JWS MUST be rejected. 470 Note that ECDSA digital signature contains a value referred to as K, 471 which is a random number generated for each digital signature 472 instance. This means that two ECDSA digital signatures using exactly 473 the same input parameters will output different signature values 474 because their K values will be different. A consequence of this is 475 that one cannot validate an ECDSA signature by recomputing the 476 signature and comparing the results. 478 Signing with the ECDSA P-384 SHA-384 and ECDSA P-521 SHA-512 479 algorithms is performed identically to the procedure for ECDSA P-256 480 SHA-256 - just using the corresponding hash algorithm with 481 correspondingly larger result values. For ECDSA P-384 SHA-384, R and 482 S will be 48 bytes each, resulting in a 96 byte array. For ECDSA 483 P-521 SHA-512, R and S will be 66 bytes each (so they can represent a 484 521-bit integer), resulting in a 132 byte array. 486 3.5. Using the Algorithm "none" 488 JWSs MAY also be created that do not provide integrity protection. 489 Such a JWS is called a "Plaintext JWS". Plaintext JWSs MUST use the 490 "alg" value "none", and are formatted identically to other JWSs, but 491 with an empty JWS Signature value. 493 3.6. Additional Digital Signature/MAC Algorithms and Parameters 495 Additional algorithms MAY be used to protect JWSs with corresponding 496 "alg" (algorithm) header parameter values being defined to refer to 497 them. New "alg" header parameter values SHOULD either be registered 498 in the IANA JSON Web Signature and Encryption Algorithms registry 499 Section 6.1 or be a URI that contains a Collision Resistant 500 Namespace. In particular, it is permissible to use the algorithm 501 identifiers defined in XML DSIG [RFC3275], XML DSIG 2.0 502 [W3C.CR-xmldsig-core2-20120124], and related specifications as "alg" 503 values. 505 As indicated by the common registry, JWSs and JWEs share a common 506 "alg" value space. The values used by the two specifications MUST be 507 distinct, as the "alg" value MAY be used to determine whether the 508 object is a JWS or JWE. 510 Likewise, additional reserved header parameter names MAY be defined 511 via the IANA JSON Web Signature and Encryption Header Parameters 512 registry [JWS]. As indicated by the common registry, JWSs and JWEs 513 share a common header parameter space; when a parameter is used by 514 both specifications, its usage must be compatible between the 515 specifications. 517 4. Cryptographic Algorithms for JWE 519 JWE uses cryptographic algorithms to encrypt the Content Master Key 520 (CMK) and the Plaintext. This section specifies a set of specific 521 algorithms for these purposes. 523 4.1. "alg" (Algorithm) Header Parameter Values for JWE 525 The table below is the set of "alg" (algorithm) header parameter 526 values that are defined by this specification for use with JWE. 527 These algorithms are used to encrypt the CMK, producing the JWE 528 Encrypted Key, or to use key agreement to agree upon the CMK. 530 +-----------+--------------------------------------+----------------+ 531 | alg | Key Encryption or Agreement | Implementation | 532 | Parameter | Algorithm | Requirements | 533 | Value | | | 534 +-----------+--------------------------------------+----------------+ 535 | RSA1_5 | RSAES-PKCS1-V1_5 [RFC3447] | REQUIRED | 536 | RSA-OAEP | RSAES using Optimal Asymmetric | OPTIONAL | 537 | | Encryption Padding (OAEP) [RFC3447], | | 538 | | with the default parameters | | 539 | | specified by RFC 3447 in Section | | 540 | | A.2.1 | | 541 | ECDH-ES | Elliptic Curve Diffie-Hellman | RECOMMENDED+ | 542 | | Ephemeral Static [RFC6090], and | | 543 | | using the Concat KDF, as defined in | | 544 | | Section 5.8.1 of [NIST.800-56A], | | 545 | | where the Digest Method is SHA-256 | | 546 | | and all OtherInfo parameters are the | | 547 | | empty bit string | | 548 | A128KW | Advanced Encryption Standard (AES) | RECOMMENDED | 549 | | Key Wrap Algorithm [RFC3394] using | | 550 | | 128 bit keys | | 551 | A256KW | AES Key Wrap Algorithm using 256 bit | RECOMMENDED | 552 | | keys | | 553 +-----------+--------------------------------------+----------------+ 555 The use of "+" in the Implementation Requirements indicates that the 556 requirement strength is likely to be increased in a future version of 557 the specification. 559 4.2. "enc" (Encryption Method) Header Parameter Values for JWE 561 The table below is the set of "enc" (encryption method) header 562 parameter values that are defined by this specification for use with 563 JWE. These algorithms are used to encrypt the Plaintext, which 564 produces the Ciphertext. 566 +-----------+--------------------------------------+----------------+ 567 | enc | Block Encryption Algorithm | Implementation | 568 | Parameter | | Requirements | 569 | Value | | | 570 +-----------+--------------------------------------+----------------+ 571 | A128CBC | Advanced Encryption Standard (AES) | REQUIRED | 572 | | in Cipher Block Chaining (CBC) mode | | 573 | | with PKCS #5 padding [AES] | | 574 | | [NIST.800-38A] using 128 bit keys | | 575 | A256CBC | AES in CBC mode with PKCS #5 padding | REQUIRED | 576 | | using 256 bit keys | | 577 | A128GCM | AES in Galois/Counter Mode (GCM) | RECOMMENDED | 578 | | [AES] [NIST.800-38D] using 128 bit | | 579 | | keys | | 580 | A256GCM | AES GCM using 256 bit keys | RECOMMENDED | 581 +-----------+--------------------------------------+----------------+ 583 All the names are short because a core goal of JWE is for the 584 representations to be compact. However, there is no a priori length 585 restriction on "alg" values. 587 See Appendix B for a table cross-referencing the encryption "alg" 588 (algorithm) and "enc" (encryption method) values used in this 589 specification with the equivalent identifiers used by other standards 590 and software packages. 592 4.3. "int" (Integrity Algorithm) Header Parameter Values for JWE 594 The table below is the set of "int" (integrity algorithm) header 595 parameter values defined by this specification for use with JWE. 596 Note that these are the HMAC SHA subset of the "alg" (algorithm) 597 header parameter values defined for use with JWS Section 3.1. 599 +-----------------+-------------------------+-----------------------+ 600 | int Parameter | Algorithm | Implementation | 601 | Value | | Requirements | 602 +-----------------+-------------------------+-----------------------+ 603 | HS256 | HMAC using SHA-256 hash | REQUIRED | 604 | | algorithm | | 605 | HS384 | HMAC using SHA-384 hash | OPTIONAL | 606 | | algorithm | | 607 | HS512 | HMAC using SHA-512 hash | OPTIONAL | 608 | | algorithm | | 609 +-----------------+-------------------------+-----------------------+ 611 4.4. "kdf" (Key Derivation Function) Header Parameter Values for JWE 613 The table below is the set of "kdf" (key derivation function) header 614 parameter values defined by this specification for use with JWE. 616 +-----------+--------------------------------------+----------------+ 617 | kdf | Algorithm | Implementation | 618 | Parameter | | Requirements | 619 | Value | | | 620 +-----------+--------------------------------------+----------------+ 621 | CS256 | Concat KDF, as defined in Section | REQUIRED | 622 | | 5.8.1 of [NIST.800-56A], with | | 623 | | parameters per Section 4.12, using | | 624 | | SHA-256 as the digest method | | 625 | CS384 | Concat KDF with parameters per | OPTIONAL | 626 | | Section 4.12, using SHA-384 as the | | 627 | | digest method | | 628 | CS512 | Concat KDF with parameters per | OPTIONAL | 629 | | Section 4.12, using SHA-512 as the | | 630 | | digest method | | 631 +-----------+--------------------------------------+----------------+ 633 4.5. Key Encryption with RSAES-PKCS1-V1_5 635 This section defines the specifics of encrypting a JWE CMK with 636 RSAES-PKCS1-V1_5 [RFC3447]. The "alg" header parameter value 637 "RSA1_5" is used in this case. 639 A key of size 2048 bits or larger MUST be used with this algorithm. 641 4.6. Key Encryption with RSAES OAEP 643 This section defines the specifics of encrypting a JWE CMK with RSAES 644 using Optimal Asymmetric Encryption Padding (OAEP) [RFC3447], with 645 the default parameters specified by RFC 3447 in Section A.2.1. The 646 "alg" header parameter value "RSA-OAEP" is used in this case. 648 A key of size 2048 bits or larger MUST be used with this algorithm. 650 4.7. Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static 651 (ECDH-ES) 653 This section defines the specifics of agreeing upon a JWE CMK with 654 Elliptic Curve Diffie-Hellman Ephemeral Static [RFC6090], and using 655 the Concat KDF, as defined in Section 5.8.1 of [NIST.800-56A], where 656 the Digest Method is SHA-256 and all OtherInfo parameters are the 657 empty bit string. The "alg" header parameter value "ECDH-ES" is used 658 in this case. 660 The output of the Concat KDF MUST be a key of the same length as that 661 used by the "enc" algorithm. 663 A new "epk" (ephemeral public key) value MUST be generated for each 664 key agreement transaction. 666 4.8. Key Encryption with AES Key Wrap 668 This section defines the specifics of encrypting a JWE CMK with the 669 Advanced Encryption Standard (AES) Key Wrap Algorithm [RFC3394] using 670 128 or 256 bit keys. The "alg" header parameter values "A128KW" or 671 "A256KW" are used in this case. 673 4.9. Plaintext Encryption with AES CBC Mode 675 This section defines the specifics of encrypting the JWE Plaintext 676 with Advanced Encryption Standard (AES) in Cipher Block Chaining 677 (CBC) mode with PKCS #5 padding [AES] [NIST.800-38A] using 128 or 256 678 bit keys. The "enc" header parameter values "A128CBC" or "A256CBC" 679 are used in this case. 681 Use of an initialization vector of size 128 bits is REQUIRED with 682 this algorithm. 684 4.10. Plaintext Encryption with AES GCM 686 This section defines the specifics of encrypting the JWE Plaintext 687 with Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) 688 [AES] [NIST.800-38D] using 128 or 256 bit keys. The "enc" header 689 parameter values "A128GCM" or "A256GCM" are used in this case. 691 Use of an initialization vector of size 96 bits is REQUIRED with this 692 algorithm. 694 The "additional authenticated data" parameter is used to secure the 695 header and key values, as specified for AEAD algorithms in Section 5 696 of [JWE]. 698 The requested size of the "authentication tag" output MUST be 128 699 bits, regardless of the key size. 701 As GCM is an AEAD algorithm, the JWE Integrity Value is set to be the 702 "authentication tag" value produced by the encryption. 704 4.11. Integrity Calculation with HMAC SHA-256, HMAC SHA-384, or HMAC 705 SHA-512 707 This section defines the specifics of computing a JWE Integrity Value 708 with HMAC SHA-256, HMAC SHA-384, or HMAC SHA-512 [SHS]. Other than 709 as stated below, these computations are performed identically to 710 those specified in Section 3.2. 712 A key of the same size as the hash output (for instance, 256 bits for 713 "HS256") MUST be used with this algorithm. 715 Per Section 9 of [JWE], the JWS Secured Input value used contains the 716 header, encrypted key, and ciphertext. 718 4.12. Key Derivation with Concat KDF and SHA-256, SHA-384, or SHA-512 720 The key derivation process derives CEK and CIK values from the CMK. 721 It uses as a primitive a Key Derivation Function (KDF) which 722 notionally takes three arguments: 724 MasterKey: The master key used to compute the individual use keys 725 Label: The use key label, used to differentiate individual use keys 727 Length: The desired length of the use key 729 This section defines the specifics of using the Concat KDF, as 730 defined in Section 5.8.1 of [NIST.800-56A], where the Digest Method 731 is one of SHA-256, SHA-384, or SHA-512, the SuppPubInfo parameter is 732 the Label, and the remaining OtherInfo parameters are the empty bit 733 string. 735 The "kdf" (key derivation function) header parameter values "CS256", 736 "CS384", and "CS512" are respectively used in the JWE Header to 737 indicate the use of the Concat KDF as above with the respective 738 digest methods. If the "kdf" header parameter is omitted when an 739 AEAD "enc" algorithm is not used, this is equivalent to specifying 740 use of the "CS256" key derivation function. 742 To compute the CEK from the CMK, the ASCII label "Encryption" ([69, 743 110, 99, 114, 121, 112, 116, 105, 111, 110]) is used. Use the key 744 size for the "enc" algorithm as the CEK desired key length. 746 To compute the CIK from the CMK, the ASCII label "Integrity" ([73, 747 110, 116, 101, 103, 114, 105, 116, 121]) is used. Use the minimum 748 key size for the "int" algorithm (for instance, 256 bits for "HS256") 749 as the CIK desired key length. 751 4.13. Additional Encryption Algorithms and Parameters 753 Additional algorithms MAY be used to protect JWEs with corresponding 754 "alg" (algorithm), "enc" (encryption method), and "int" (integrity 755 algorithm) header parameter values being defined to refer to them. 756 New "alg", "enc", and "int" header parameter values SHOULD either be 757 registered in the IANA JSON Web Signature and Encryption Algorithms 758 registry Section 6.1 or be a URI that contains a Collision Resistant 759 Namespace. In particular, it is permissible to use the algorithm 760 identifiers defined in XML Encryption [W3C.REC-xmlenc-core-20021210], 761 XML Encryption 1.1 [W3C.CR-xmlenc-core1-20120313], and related 762 specifications as "alg", "enc", and "int" values. 764 As indicated by the common registry, JWSs and JWEs share a common 765 "alg" value space. The values used by the two specifications MUST be 766 distinct, as the "alg" value MAY be used to determine whether the 767 object is a JWS or JWE. 769 Likewise, additional reserved header parameter names MAY be defined 770 via the IANA JSON Web Signature and Encryption Header Parameters 771 registry [JWS]. As indicated by the common registry, JWSs and JWEs 772 share a common header parameter space; when a parameter is used by 773 both specifications, its usage must be compatible between the 774 specifications. 776 5. Cryptographic Algorithms for JWK 778 A JSON Web Key (JWK) [JWK] is a JavaScript Object Notation (JSON) 779 [RFC4627] data structure that represents a public key. A JSON Web 780 Key Set (JWK Set) is a JSON data structure for representing a set of 781 JWKs. This section specifies a set of algorithm families to be used 782 for those public keys and the algorithm family specific parameters 783 for representing those keys. 785 5.1. "alg" (Algorithm Family) Parameter Values for JWK 787 The table below is the set of "alg" (algorithm family) parameter 788 values that are defined by this specification for use in JWKs. 790 +-----------------+-------------------------+-----------------------+ 791 | alg Parameter | Algorithm Family | Implementation | 792 | Value | | Requirements | 793 +-----------------+-------------------------+-----------------------+ 794 | EC | Elliptic Curve [DSS] | RECOMMENDED+ | 795 | | key family | | 796 | RSA | RSA [RFC3447] key | REQUIRED | 797 | | family | | 798 +-----------------+-------------------------+-----------------------+ 800 All the names are short because a core goal of JWK is for the 801 representations to be compact. However, there is no a priori length 802 restriction on "alg" values. 804 The use of "+" in the Implementation Requirements indicates that the 805 requirement strength is likely to be increased in a future version of 806 the specification. 808 5.2. JWK Parameters for Elliptic Curve Keys 810 JWKs can represent Elliptic Curve [DSS] keys. In this case, the 811 "alg" member value MUST be "EC". Furthermore, these additional 812 members MUST be present: 814 5.2.1. "crv" (Curve) Parameter 816 The "crv" (curve) member identifies the cryptographic curve used with 817 the key. Curve values from [DSS] used by this specification are: 819 o "P-256" 821 o "P-384" 823 o "P-521" 825 Additional "crv" values MAY be used, provided they are understood by 826 implementations using that Elliptic Curve key. The "crv" value is 827 case sensitive. Its value MUST be a string. 829 5.2.2. "x" (X Coordinate) Parameter 831 The "x" (x coordinate) member contains the x coordinate for the 832 elliptic curve point. It is represented as the base64url encoding of 833 the coordinate's big endian representation. 835 5.2.3. "y" (Y Coordinate) Parameter 837 The "y" (y coordinate) member contains the y coordinate for the 838 elliptic curve point. It is represented as the base64url encoding of 839 the coordinate's big endian representation. 841 5.3. JWK Parameters for RSA Keys 843 JWKs can represent RSA [RFC3447] keys. In this case, the "alg" 844 member value MUST be "RSA". Furthermore, these additional members 845 MUST be present: 847 5.3.1. "mod" (Modulus) Parameter 849 The "mod" (modulus) member contains the modulus value for the RSA 850 public key. It is represented as the base64url encoding of the 851 value's unsigned big endian representation. 853 5.3.2. "exp" (Exponent) Parameter 855 The "exp" (exponent) member contains the exponent value for the RSA 856 public key. It is represented as the base64url encoding of the 857 value's unsigned big endian representation. 859 5.4. Additional Key Algorithm Families and Parameters 861 Public keys using additional algorithm families MAY be represented 862 using JWK data structures with corresponding "alg" (algorithm family) 863 parameter values being defined to refer to them. New "alg" parameter 864 values SHOULD either be registered in the IANA JSON Web Key Algorithm 865 Families registry Section 6.2 or be a URI that contains a Collision 866 Resistant Namespace. 868 Likewise, parameters for representing keys for additional algorithm 869 families or additional key properties SHOULD either be registered in 870 the IANA JSON Web Key Parameters registry [JWK] or be a URI that 871 contains a Collision Resistant Namespace. 873 6. IANA Considerations 875 The following registration procedure is used for all the registries 876 established by this specification. 878 Values are registered with a Specification Required [RFC5226] after a 879 two week review period on the [TBD]@ietf.org mailing list, on the 880 advice of one or more Designated Experts. However, to allow for the 881 allocation of values prior to publication, the Designated Expert(s) 882 may approve registration once they are satisfied that such a 883 specification will be published. 885 Registration requests must be sent to the [TBD]@ietf.org mailing list 886 for review and comment, with an appropriate subject (e.g., "Request 887 for access token type: example"). [[ Note to RFC-EDITOR: The name of 888 the mailing list should be determined in consultation with the IESG 889 and IANA. Suggested name: jose-reg-review. ]] 891 Within the review period, the Designated Expert(s) will either 892 approve or deny the registration request, communicating this decision 893 to the review list and IANA. Denials should include an explanation 894 and, if applicable, suggestions as to how to make the request 895 successful. 897 IANA must only accept registry updates from the Designated Expert(s), 898 and should direct all requests for registration to the review mailing 899 list. 901 6.1. JSON Web Signature and Encryption Algorithms Registry 903 This specification establishes the IANA JSON Web Signature and 904 Encryption Algorithms registry for values of the JWS and JWE "alg" 905 (algorithm), "enc" (encryption method), and "int" (integrity 906 algorithm) header parameters. The registry records the algorithm 907 name, the algorithm usage locations from the set "alg", "enc", and 908 "int", implementation requirements, and a reference to the 909 specification that defines it. The same algorithm name may be 910 registered multiple times, provided that the sets of usage locations 911 are disjoint. The implementation requirements of an algorithm may be 912 changed over time by the Designated Experts(s) as the cryptographic 913 landscape evolves, for instance, to change the status of an algorithm 914 to DEPRECATED, or to change the status of an algorithm from OPTIONAL 915 to RECOMMENDED or REQUIRED. 917 6.1.1. Registration Template 919 Algorithm Name: 920 The name requested (e.g., "example"). 922 Algorithm Usage Location(s): 923 The algorithm usage, which must be one or more of the values 924 "alg", "enc", "int", or "kdf". 926 Implementation Requirements: 927 The algorithm implementation requirements, which must be one the 928 words REQUIRED, RECOMMENDED, OPTIONAL, or DEPRECATED. Optionally, 929 the word may be followed by a "+" or "-". The use of "+" 930 indicates that the requirement strength is likely to be increased 931 in a future version of the specification. The use of "-" 932 indicates that the requirement strength is likely to be decreased 933 in a future version of the specification. 935 Change Controller: 936 For standards-track RFCs, state "IETF". For others, give the name 937 of the responsible party. Other details (e.g., postal address, 938 e-mail address, home page URI) may also be included. 940 Specification Document(s): 941 Reference to the document that specifies the parameter, preferably 942 including a URI that can be used to retrieve a copy of the 943 document. An indication of the relevant sections may also be 944 included, but is not required. 946 6.1.2. Initial Registry Contents 948 o Algorithm Name: "HS256" 950 o Algorithm Usage Location(s): "alg", "int" 952 o Implementation Requirements: REQUIRED 954 o Change Controller: IETF 956 o Specification Document(s): Section 3.1 and Section 4.3 of [[ this 957 document ]] 959 o Algorithm Name: "HS384" 961 o Algorithm Usage Location(s): "alg", "int" 962 o Implementation Requirements: OPTIONAL 964 o Change Controller: IETF 966 o Specification Document(s): Section 3.1 and Section 4.3 of [[ this 967 document ]] 969 o Algorithm Name: "HS512" 971 o Algorithm Usage Location(s): "alg", "int" 973 o Implementation Requirements: OPTIONAL 975 o Change Controller: IETF 977 o Specification Document(s): Section 3.1 and Section 4.3 of [[ this 978 document ]] 980 o Algorithm Name: "RS256" 982 o Algorithm Usage Location(s): "alg" 984 o Implementation Requirements: RECOMMENDED 986 o Change Controller: IETF 988 o Specification Document(s): Section 3.1 of [[ this document ]] 990 o Algorithm Name: "RS384" 992 o Algorithm Usage Location(s): "alg" 994 o Implementation Requirements: OPTIONAL 996 o Change Controller: IETF 998 o Specification Document(s): Section 3.1 of [[ this document ]] 1000 o Algorithm Name: "RS512" 1002 o Algorithm Usage Location(s): "alg" 1004 o Implementation Requirements: OPTIONAL 1006 o Change Controller: IETF 1008 o Specification Document(s): Section 3.1 of [[ this document ]] 1009 o Algorithm Name: "ES256" 1011 o Algorithm Usage Location(s): "alg" 1013 o Implementation Requirements: RECOMMENDED+ 1015 o Change Controller: IETF 1017 o Specification Document(s): Section 3.1 of [[ this document ]] 1019 o Algorithm Name: "ES384" 1021 o Algorithm Usage Location(s): "alg" 1023 o Implementation Requirements: OPTIONAL 1025 o Change Controller: IETF 1027 o Specification Document(s): Section 3.1 of [[ this document ]] 1029 o Algorithm Name: "ES512" 1031 o Algorithm Usage Location(s): "alg" 1033 o Implementation Requirements: OPTIONAL 1035 o Change Controller: IETF 1037 o Specification Document(s): Section 3.1 of [[ this document ]] 1039 o Algorithm Name: "none" 1041 o Algorithm Usage Location(s): "alg" 1043 o Implementation Requirements: REQUIRED 1045 o Change Controller: IETF 1047 o Specification Document(s): Section 3.1 of [[ this document ]] 1049 o Algorithm Name: "RSA1_5" 1051 o Algorithm Usage Location(s): "alg" 1053 o Implementation Requirements: REQUIRED 1055 o Change Controller: IETF 1056 o Specification Document(s): Section 4.1 of [[ this document ]] 1058 o Algorithm Name: "RSA-OAEP" 1060 o Algorithm Usage Location(s): "alg" 1062 o Implementation Requirements: OPTIONAL 1064 o Change Controller: IETF 1066 o Specification Document(s): Section 4.1 of [[ this document ]] 1068 o Algorithm Name: "ECDH-ES" 1070 o Algorithm Usage Location(s): "alg" 1072 o Implementation Requirements: RECOMMENDED+ 1074 o Change Controller: IETF 1076 o Specification Document(s): Section 4.1 of [[ this document ]] 1078 o Algorithm Name: "A128KW" 1080 o Algorithm Usage Location(s): "alg" 1082 o Implementation Requirements: RECOMMENDED 1084 o Change Controller: IETF 1086 o Specification Document(s): Section 4.1 of [[ this document ]] 1088 o Algorithm Name: "A256KW" 1090 o Algorithm Usage Location(s): "alg" 1092 o Implementation Requirements: RECOMMENDED 1094 o Change Controller: IETF 1096 o Specification Document(s): Section 4.1 of [[ this document ]] 1098 o Algorithm Name: "A128CBC" 1100 o Algorithm Usage Location(s): "enc" 1102 o Implementation Requirements: REQUIRED 1103 o Change Controller: IETF 1105 o Specification Document(s): Section 4.2 of [[ this document ]] 1107 o Algorithm Name: "A256CBC" 1109 o Algorithm Usage Location(s): "enc" 1111 o Implementation Requirements: REQUIRED 1113 o Change Controller: IETF 1115 o Specification Document(s): Section 4.2 of [[ this document ]] 1117 o Algorithm Name: "A128GCM" 1119 o Algorithm Usage Location(s): "enc" 1121 o Implementation Requirements: RECOMMENDED 1123 o Change Controller: IETF 1125 o Specification Document(s): Section 4.2 of [[ this document ]] 1127 o Algorithm Name: "A256GCM" 1129 o Algorithm Usage Location(s): "enc" 1131 o Implementation Requirements: RECOMMENDED 1133 o Change Controller: IETF 1135 o Specification Document(s): Section 4.2 of [[ this document ]] 1137 o Algorithm Name: "CS256" 1139 o Algorithm Usage Location(s): "kdf" 1141 o Implementation Requirements: REQUIRED 1143 o Change Controller: IETF 1145 o Specification Document(s): Section 4.4 of [[ this document ]] 1147 o Algorithm Name: "CS384" 1149 o Algorithm Usage Location(s): "kdf" 1150 o Implementation Requirements: OPTIONAL 1152 o Change Controller: IETF 1154 o Specification Document(s): Section 4.4 of [[ this document ]] 1156 o Algorithm Name: "CS512" 1158 o Algorithm Usage Location(s): "kdf" 1160 o Implementation Requirements: OPTIONAL 1162 o Change Controller: IETF 1164 o Specification Document(s): Section 4.4 of [[ this document ]] 1166 6.2. JSON Web Key Algorithm Families Registry 1168 This specification establishes the IANA JSON Web Key Algorithm 1169 Families registry for values of the JWK "alg" (algorithm family) 1170 parameter. The registry records the "alg" value and a reference to 1171 the specification that defines it. This specification registers the 1172 values defined in Section 5.1. 1174 6.2.1. Registration Template 1176 "alg" Parameter Value: 1177 The name requested (e.g., "example"). 1179 Change Controller: 1180 For standards-track RFCs, state "IETF". For others, give the name 1181 of the responsible party. Other details (e.g., postal address, 1182 e-mail address, home page URI) may also be included. 1184 Implementation Requirements: 1185 The algorithm implementation requirements, which must be one the 1186 words REQUIRED, RECOMMENDED, OPTIONAL, or DEPRECATED. Optionally, 1187 the word may be followed by a "+" or "-". The use of "+" 1188 indicates that the requirement strength is likely to be increased 1189 in a future version of the specification. The use of "-" 1190 indicates that the requirement strength is likely to be decreased 1191 in a future version of the specification. 1193 Specification Document(s): 1194 Reference to the document that specifies the parameter, preferably 1195 including a URI that can be used to retrieve a copy of the 1196 document. An indication of the relevant sections may also be 1197 included, but is not required. 1199 6.2.2. Initial Registry Contents 1201 o "alg" Parameter Value: "EC" 1203 o Implementation Requirements: RECOMMENDED+ 1205 o Change Controller: IETF 1207 o Specification Document(s): Section 5.1 of [[ this document ]] 1209 o "alg" Parameter Value: "RSA" 1211 o Implementation Requirements: REQUIRED 1213 o Change Controller: IETF 1215 o Specification Document(s): Section 5.1 of [[ this document ]] 1217 6.3. JSON Web Key Parameters Registration 1219 This specification registers the parameter names defined in 1220 Section 5.2 and Section 5.3 in the IANA JSON Web Key Parameters 1221 registry [JWK]. 1223 6.3.1. Registry Contents 1225 o Parameter Name: "crv" 1227 o Change Controller: IETF 1229 o Specification Document(s): Section 5.2.1 of [[ this document ]] 1231 o Parameter Name: "x" 1233 o Change Controller: IETF 1235 o Specification Document(s): Section 5.2.2 of [[ this document ]] 1237 o Parameter Name: "y" 1239 o Change Controller: IETF 1241 o Specification Document(s): Section 5.2.3 of [[ this document ]] 1243 o Parameter Name: "mod" 1245 o Change Controller: IETF 1246 o Specification Document(s): Section 5.3.1 of [[ this document ]] 1248 o Parameter Name: "exp" 1250 o Change Controller: IETF 1252 o Specification Document(s): Section 5.3.2 of [[ this document ]] 1254 7. Security Considerations 1256 All of the security issues faced by any cryptographic application 1257 must be faced by a JWS/JWE/JWK agent. Among these issues are 1258 protecting the user's private key, preventing various attacks, and 1259 helping the user avoid mistakes such as inadvertently encrypting a 1260 message for the wrong recipient. The entire list of security 1261 considerations is beyond the scope of this document, but some 1262 significant concerns are listed here. 1264 The security considerations in [AES], [DSS], [JWE], [JWK], [JWS], 1265 [NIST.800-38A], [NIST.800-38D], [NIST.800-56A], [RFC2104], [RFC3394], 1266 [RFC3447], [RFC5116], [RFC6090], and [SHS] apply to this 1267 specification. 1269 Eventually the algorithms and/or key sizes currently described in 1270 this specification will no longer be considered sufficiently secure 1271 and will be removed. Therefore, implementers and deployments must be 1272 prepared for this eventuality. 1274 Algorithms of matching strength should be used together whenever 1275 possible. For instance, when AES Key Wrap is used with a given key 1276 size, using the same key size for AES CBC or GCM is recommended. 1277 Likewise, when AES CBC is used with a 128 bit key, using HMAC SHA-256 1278 as the integrity algorithm is recommended, whereas when AES CBC is 1279 used with a 256 bit key, using HMAC SHA-512 as the integrity 1280 algorithm is recommended. 1282 While Section 8 of RFC 3447 [RFC3447] explicitly calls for people not 1283 to adopt RSASSA-PKCS1 for new applications and instead requests that 1284 people transition to RSASSA-PSS, this specification does include 1285 RSASSA-PKCS1, for interoperability reasons, because it commonly 1286 implemented. 1288 Keys used with RSAES-PKCS1-v1_5 must follow the constraints in 1289 Section 7.2 of RFC 3447 [RFC3447]. In particular, keys with a low 1290 public key exponent value must not be used. 1292 Plaintext JWSs (JWSs that use the "alg" value "none") provide no 1293 integrity protection. Thus, they must only be used in contexts where 1294 the payload is secured by means other than a digital signature or MAC 1295 value, or need not be secured. 1297 Receiving agents that validate signatures and sending agents that 1298 encrypt messages need to be cautious of cryptographic processing 1299 usage when validating signatures and encrypting messages using keys 1300 larger than those mandated in this specification. An attacker could 1301 send certificates with keys that would result in excessive 1302 cryptographic processing, for example, keys larger than those 1303 mandated in this specification, which could swamp the processing 1304 element. Agents that use such keys without first validating the 1305 certificate to a trust anchor are advised to have some sort of 1306 cryptographic resource management system to prevent such attacks. 1308 8. Open Issues 1310 [[ to be removed by the RFC editor before publication as an RFC ]] 1312 The following items remain to be considered or done in this draft: 1314 o Should we use the "alg" value as the AlgorithmID input to the 1315 Concat KDF when doing key agreement? Or is an AlgorithmID value 1316 unnecessary in the way that we are using Concat? 1318 o Should we use the "enc" and "int" values as AlgorithmID inputs to 1319 the Concat KDF when doing key derivation? Or is an AlgorithmID 1320 value unnecessary in the way that we are using Concat? 1322 o Do we want to add AES ECB as a (non-authenticated) key wrap 1323 algorithm? 1325 9. References 1327 9.1. Normative References 1329 [AES] National Institute of Standards and Technology (NIST), 1330 "Advanced Encryption Standard (AES)", FIPS PUB 197, 1331 November 2001. 1333 [DSS] National Institute of Standards and Technology, "Digital 1334 Signature Standard (DSS)", FIPS PUB 186-3, June 2009. 1336 [JWE] Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web 1337 Encryption (JWE)", July 2012. 1339 [JWK] Jones, M., "JSON Web Key (JWK)", July 2012. 1341 [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1342 Signature (JWS)", July 2012. 1344 [NIST.800-38A] 1345 National Institute of Standards and Technology (NIST), 1346 "Recommendation for Block Cipher Modes of Operation", 1347 NIST PUB 800-38A, December 2001. 1349 [NIST.800-38D] 1350 National Institute of Standards and Technology (NIST), 1351 "Recommendation for Block Cipher Modes of Operation: 1352 Galois/Counter Mode (GCM) and GMAC", NIST PUB 800-38D, 1353 December 2001. 1355 [NIST.800-56A] 1356 National Institute of Standards and Technology (NIST), 1357 "Recommendation for Pair-Wise Key Establishment Schemes 1358 Using Discrete Logarithm Cryptography (Revised)", NIST PUB 1359 800-56A, March 2007. 1361 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1362 Hashing for Message Authentication", RFC 2104, 1363 February 1997. 1365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1366 Requirement Levels", BCP 14, RFC 2119, March 1997. 1368 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 1369 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 1371 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1372 Standards (PKCS) #1: RSA Cryptography Specifications 1373 Version 2.1", RFC 3447, February 2003. 1375 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1376 10646", STD 63, RFC 3629, November 2003. 1378 [RFC4627] Crockford, D., "The application/json Media Type for 1379 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 1381 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1382 Encodings", RFC 4648, October 2006. 1384 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1385 Encryption", RFC 5116, January 2008. 1387 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1388 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1389 May 2008. 1391 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1392 Curve Cryptography Algorithms", RFC 6090, February 2011. 1394 [SHS] National Institute of Standards and Technology, "Secure 1395 Hash Standard (SHS)", FIPS PUB 180-3, October 2008. 1397 [USASCII] American National Standards Institute, "Coded Character 1398 Set -- 7-bit American Standard Code for Information 1399 Interchange", ANSI X3.4, 1986. 1401 9.2. Informative References 1403 [CanvasApp] 1404 Facebook, "Canvas Applications", 2010. 1406 [I-D.rescorla-jsms] 1407 Rescorla, E. and J. Hildebrand, "JavaScript Message 1408 Security Format", draft-rescorla-jsms-00 (work in 1409 progress), March 2011. 1411 [JCA] Oracle, "Java Cryptography Architecture", 2011. 1413 [JSE] Bradley, J. and N. Sakimura (editor), "JSON Simple 1414 Encryption", September 2010. 1416 [JSS] Bradley, J. and N. Sakimura (editor), "JSON Simple Sign", 1417 September 2010. 1419 [MagicSignatures] 1420 Panzer (editor), J., Laurie, B., and D. Balfanz, "Magic 1421 Signatures", January 2011. 1423 [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 1424 Language) XML-Signature Syntax and Processing", RFC 3275, 1425 March 2002. 1427 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1428 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1429 July 2005. 1431 [W3C.CR-xmldsig-core2-20120124] 1432 Reagle, J., Solo, D., Datta, P., Hirsch, F., Eastlake, D., 1433 Roessler, T., Cantor, S., and K. Yiu, "XML Signature 1434 Syntax and Processing Version 2.0", World Wide Web 1435 Consortium CR CR-xmldsig-core2-20120124, January 2012, 1436 . 1438 [W3C.CR-xmlenc-core1-20120313] 1439 Eastlake, D., Reagle, J., Hirsch, F., and T. Roessler, 1440 "XML Encryption Syntax and Processing Version 1.1", World 1441 Wide Web Consortium CR CR-xmlenc-core1-20120313, 1442 March 2012, 1443 . 1445 [W3C.REC-xmlenc-core-20021210] 1446 Eastlake, D. and J. Reagle, "XML Encryption Syntax and 1447 Processing", World Wide Web Consortium Recommendation REC- 1448 xmlenc-core-20021210, December 2002, 1449 . 1451 Appendix A. Digital Signature/MAC Algorithm Identifier Cross-Reference 1453 This appendix contains a table cross-referencing the digital 1454 signature and MAC "alg" (algorithm) values used in this specification 1455 with the equivalent identifiers used by other standards and software 1456 packages. See XML DSIG [RFC3275], XML DSIG 2.0 1457 [W3C.CR-xmldsig-core2-20120124], and Java Cryptography Architecture 1458 [JCA] for more information about the names defined by those 1459 documents. 1461 +-------+-----+----------------------------+----------+-------------+ 1462 | Algor | JWS | XML DSIG | JCA | OID | 1463 | ithm | | | | | 1464 +-------+-----+----------------------------+----------+-------------+ 1465 | HMAC | HS2 | http://www.w3.org/2001/04/ | HmacSHA2 | 1.2.840.113 | 1466 | using | 56 | xmldsig-more#hmac-sha256 | 56 | 549.2.9 | 1467 | SHA-2 | | | | | 1468 | 56 | | | | | 1469 | hash | | | | | 1470 | algo | | | | | 1471 | rithm | | | | | 1472 | HMAC | HS3 | http://www.w3.org/2001/04/ | HmacSHA3 | 1.2.840.113 | 1473 | using | 84 | xmldsig-more#hmac-sha384 | 84 | 549.2.10 | 1474 | SHA-3 | | | | | 1475 | 84 | | | | | 1476 | hash | | | | | 1477 | algo | | | | | 1478 | rithm | | | | | 1479 | HMAC | HS5 | http://www.w3.org/2001/04/ | HmacSHA5 | 1.2.840.113 | 1480 | using | 12 | xmldsig-more#hmac-sha512 | 12 | 549.2.11 | 1481 | SHA-5 | | | | | 1482 | 12 | | | | | 1483 | hash | | | | | 1484 | algo | | | | | 1485 | rithm | | | | | 1486 | RSASS | RS2 | http://www.w3.org/2001/04/ | SHA256wi | 1.2.840.113 | 1487 | A | 56 | xmldsig-more#rsa-sha256 | thRSA | 549.1.1.11 | 1488 | usin | | | | | 1489 | gSHA- | | | | | 1490 | 256 | | | | | 1491 | has | | | | | 1492 | h alg | | | | | 1493 | orith | | | | | 1494 | m | | | | | 1495 | RSASS | RS3 | http://www.w3.org/2001/04/ | SHA384wi | 1.2.840.113 | 1496 | A | 84 | xmldsig-more#rsa-sha384 | thRSA | 549.1.1.12 | 1497 | usin | | | | | 1498 | gSHA- | | | | | 1499 | 384 | | | | | 1500 | has | | | | | 1501 | h alg | | | | | 1502 | orith | | | | | 1503 | m | | | | | 1504 | RSASS | RS5 | http://www.w3.org/2001/04/ | SHA512wi | 1.2.840.113 | 1505 | A | 12 | xmldsig-more#rsa-sha512 | thRSA | 549.1.1.13 | 1506 | usin | | | | | 1507 | gSHA- | | | | | 1508 | 512 | | | | | 1509 | has | | | | | 1510 | h alg | | | | | 1511 | orith | | | | | 1512 | m | | | | | 1513 | ECDSA | ES2 | http://www.w3.org/2001/04/ | SHA256wi | 1.2.840.100 | 1514 | using | 56 | xmldsig-more#ecdsa-sha256 | thECDSA | 45.4.3.2 | 1515 | P-256 | | | | | 1516 | curve | | | | | 1517 | and | | | | | 1518 | SHA-2 | | | | | 1519 | 56 | | | | | 1520 | hash | | | | | 1521 | algo | | | | | 1522 | rithm | | | | | 1523 | ECDSA | ES3 | http://www.w3.org/2001/04/ | SHA384wi | 1.2.840.100 | 1524 | using | 84 | xmldsig-more#ecdsa-sha384 | thECDSA | 45.4.3.3 | 1525 | P-384 | | | | | 1526 | curve | | | | | 1527 | and | | | | | 1528 | SHA-3 | | | | | 1529 | 84 | | | | | 1530 | hash | | | | | 1531 | algo | | | | | 1532 | rithm | | | | | 1533 | ECDSA | ES5 | http://www.w3.org/2001/04/ | SHA512wi | 1.2.840.100 | 1534 | using | 12 | xmldsig-more#ecdsa-sha512 | thECDSA | 45.4.3.4 | 1535 | P-521 | | | | | 1536 | curve | | | | | 1537 | and | | | | | 1538 | SHA-5 | | | | | 1539 | 12 | | | | | 1540 | hash | | | | | 1541 | algo | | | | | 1542 | rithm | | | | | 1543 +-------+-----+----------------------------+----------+-------------+ 1545 Appendix B. Encryption Algorithm Identifier Cross-Reference 1547 This appendix contains a table cross-referencing the "alg" 1548 (algorithm) and "enc" (encryption method) values used in this 1549 specification with the equivalent identifiers used by other standards 1550 and software packages. See XML Encryption 1551 [W3C.REC-xmlenc-core-20021210], XML Encryption 1.1 1552 [W3C.CR-xmlenc-core1-20120313], and Java Cryptography Architecture 1553 [JCA] for more information about the names defined by those 1554 documents. 1556 +----------+------+---------------------------+---------------------+ 1557 | Algorith | JWE | XML ENC | JCA | 1558 | m | | | | 1559 +----------+------+---------------------------+---------------------+ 1560 | RSAES-PK | RSA1 | http://www.w3.org/2001/04 | RSA/None/PKCS1Paddi | 1561 | CS1-V1_5 | _5 | /xmlenc#rsa-1_5 | ng | 1562 | RSAES | RSA- | http://www.w3.org/2001/04 | RSA/None/OAEPWithSH | 1563 | using | OAEP | /xmlenc#rsa-oaep-mgf1p | A-1AndMGF1Padding | 1564 | Optimal | | | | 1565 | Asymmetr | | | | 1566 | ic | | | | 1567 | Encrypt | | | | 1568 | ion | | | | 1569 | Paddin | | | | 1570 | g (OAEP) | | | | 1571 | Elliptic | ECDH | http://www.w3.org/2009/xm | | 1572 | Curve | -ES | lenc11#ECDH-ES | | 1573 | Diffie-H | | | | 1574 | ellman | | | | 1575 | Ephemer | | | | 1576 | alStatic | | | | 1577 | Advanced | A128 | http://www.w3.org/2001/04 | | 1578 | Encrypti | KW | /xmlenc#kw-aes128 | | 1579 | on | | | | 1580 | Standar | | | | 1581 | d(AES) | | | | 1582 | Key Wra | | | | 1583 | pAlgorit | | | | 1584 | hmusing | | | | 1585 | 128 bi | | | | 1586 | t keys | | | | 1587 | AES Key | A256 | http://www.w3.org/2001/04 | | 1588 | Wrap | KW | /xmlenc#kw-aes256 | | 1589 | Algorith | | | | 1590 | musing | | | | 1591 | 256 bit | | | | 1592 | keys | | | | 1593 | AES in | A128 | http://www.w3.org/2001/04 | AES/CBC/PKCS5Paddin | 1594 | Cipher | CBC | /xmlenc#aes128-cbc | g | 1595 | Block | | | | 1596 | Chaining | | | | 1597 | (CBC) | | | | 1598 | mode | | | | 1599 | with | | | | 1600 | PKCS #5 | | | | 1601 | padding | | | | 1602 | using | | | | 1603 | 128 bit | | | | 1604 | keys | | | | 1605 | AES in | A256 | http://www.w3.org/2001/04 | AES/CBC/PKCS5Paddin | 1606 | CBC mode | CBC | /xmlenc#aes256-cbc | g | 1607 | with | | | | 1608 | PKCS #5 | | | | 1609 | padding | | | | 1610 | using | | | | 1611 | 256 bit | | | | 1612 | keys | | | | 1613 | AES in | A128 | http://www.w3.org/2009/xm | AES/GCM/NoPadding | 1614 | Galois/C | GCM | lenc11#aes128-gcm | | 1615 | ounter | | | | 1616 | Mode | | | | 1617 | (GCM) | | | | 1618 | using | | | | 1619 | 128 bit | | | | 1620 | keys | | | | 1621 | AES GCM | A256 | http://www.w3.org/2009/xm | AES/GCM/NoPadding | 1622 | using | GCM | lenc11#aes256-gcm | | 1623 | 256 bit | | | | 1624 | keys | | | | 1625 +----------+------+---------------------------+---------------------+ 1627 Appendix C. Acknowledgements 1629 Solutions for signing and encrypting JSON content were previously 1630 explored by Magic Signatures [MagicSignatures], JSON Simple Sign 1631 [JSS], Canvas Applications [CanvasApp], JSON Simple Encryption [JSE], 1632 and JavaScript Message Security Format [I-D.rescorla-jsms], all of 1633 which influenced this draft. Dirk Balfanz, John Bradley, Yaron Y. 1634 Goland, John Panzer, Nat Sakimura, and Paul Tarjan all made 1635 significant contributions to the design of this specification and its 1636 related specifications. 1638 Appendix D. Document History 1640 [[ to be removed by the RFC editor before publication as an RFC ]] 1642 -03 1644 o Always use a 128 bit "authentication tag" size for AES GCM, 1645 regardless of the key size. 1647 o Specified that use of a 128 bit IV is REQUIRED with AES CBC. It 1648 was previously RECOMMENDED. 1650 o Removed key size language for ECDSA algorithms, since the key size 1651 is implied by the algorithm being used. 1653 o Stated that the "int" key size must be the same as the hash output 1654 size (and not larger, as was previously allowed) so that its size 1655 is defined for key generation purposes. 1657 o Added the "kdf" (key derivation function) header parameter to 1658 provide crypto agility for key derivation. The default KDF 1659 remains the Concat KDF with the SHA-256 digest function. 1661 o Clarified that the "mod" and "exp" values are unsigned. 1663 o Added Implementation Requirements columns to algorithm tables and 1664 Implementation Requirements entries to algorithm registries. 1666 o Changed AES Key Wrap to RECOMMENDED. 1668 o Moved registries JSON Web Signature and Encryption Header 1669 Parameters and JSON Web Signature and Encryption Type Values to 1670 the JWS specification. 1672 o Moved JSON Web Key Parameters registry to the JWK specification. 1674 o Changed registration requirements from RFC Required to 1675 Specification Required with Expert Review. 1677 o Added Registration Template sections for defined registries. 1679 o Added Registry Contents sections to populate registry values. 1681 o No longer say "the UTF-8 representation of the JWS Secured Input 1682 (which is the same as the ASCII representation)". Just call it 1683 "the ASCII representation of the JWS Secured Input". 1685 o Added "Collision Resistant Namespace" to the terminology section. 1687 o Numerous editorial improvements. 1689 -02 1691 o For AES GCM, use the "additional authenticated data" parameter to 1692 provide integrity for the header, encrypted key, and ciphertext 1693 and use the resulting "authentication tag" value as the JWE 1694 Integrity Value. 1696 o Defined minimum required key sizes for algorithms without 1697 specified key sizes. 1699 o Defined KDF output key sizes. 1701 o Specified the use of PKCS #5 padding with AES-CBC. 1703 o Generalized text to allow key agreement to be employed as an 1704 alternative to key wrapping or key encryption. 1706 o Clarified that ECDH-ES is a key agreement algorithm. 1708 o Required implementation of AES-128-KW and AES-256-KW. 1710 o Removed the use of "A128GCM" and "A256GCM" for key wrapping. 1712 o Removed "A512KW" since it turns out that it's not a standard 1713 algorithm. 1715 o Clarified the relationship between "typ" header parameter values 1716 and MIME types. 1718 o Generalized language to refer to Message Authentication Codes 1719 (MACs) rather than Hash-based Message Authentication Codes (HMACs) 1720 unless in a context specific to HMAC algorithms. 1722 o Established registries: JSON Web Signature and Encryption Header 1723 Parameters, JSON Web Signature and Encryption Algorithms, JSON Web 1724 Signature and Encryption "typ" Values, JSON Web Key Parameters, 1725 and JSON Web Key Algorithm Families. 1727 o Moved algorithm-specific definitions from JWK to JWA. 1729 o Reformatted to give each member definition its own section 1730 heading. 1732 -01 1734 o Moved definition of "alg":"none" for JWSs here from the JWT 1735 specification since this functionality is likely to be useful in 1736 more contexts that just for JWTs. 1738 o Added Advanced Encryption Standard (AES) Key Wrap Algorithm using 1739 512 bit keys ("A512KW"). 1741 o Added text "Alternatively, the Encoded JWS Signature MAY be 1742 base64url decoded to produce the JWS Signature and this value can 1743 be compared with the computed HMAC value, as this comparison 1744 produces the same result as comparing the encoded values". 1746 o Corrected the Magic Signatures reference. 1748 o Made other editorial improvements suggested by JOSE working group 1749 participants. 1751 -00 1753 o Created the initial IETF draft based upon 1754 draft-jones-json-web-signature-04 and 1755 draft-jones-json-web-encryption-02 with no normative changes. 1757 o Changed terminology to no longer call both digital signatures and 1758 HMACs "signatures". 1760 Author's Address 1762 Michael B. Jones 1763 Microsoft 1765 Email: mbj@microsoft.com 1766 URI: http://self-issued.info/