TOC 

The JSON Web Algorithms (JWA) specification enumerates cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS) and JSON Web Encryption (JWE) specifications.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].
This InternetDraft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
InternetDrafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as InternetDrafts. The list of current InternetDrafts is at http://datatracker.ietf.org/drafts/current/.
InternetDrafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use InternetDrafts as reference material or to cite them other than as “work in progress.”
This InternetDraft will expire on November 13, 2012.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/licenseinfo) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1.
Introduction
2.
Terminology
3.
Cryptographic Algorithms for JWS
3.1.
"alg" (Algorithm) Header Parameter Values for JWS
3.2.
MAC with HMAC SHA256, HMAC SHA384, or HMAC SHA512
3.3.
Digital Signature with RSA SHA256, RSA SHA384, or RSA SHA512
3.4.
Digital Signature with ECDSA P256 SHA256, ECDSA P384 SHA384, or ECDSA P521 SHA512
3.5.
Creating a Plaintext JWS
3.6.
Additional Digital Signature/MAC Algorithms and Parameters
4.
Cryptographic Algorithms for JWE
4.1.
"alg" (Algorithm) Header Parameter Values for JWE
4.2.
"enc" (Encryption Method) Header Parameter Values for JWE
4.3.
"int" (Integrity Algorithm) Header Parameter Values for JWE
4.4.
Key Encryption with RSA using RSAPKCS11.5 Padding
4.5.
Key Encryption with RSA using Optimal Asymmetric Encryption Padding (OAEP)
4.6.
Key Agreement with Elliptic Curve DiffieHellman Ephemeral Static (ECDHES)
4.7.
Key Encryption with AES Key Wrap
4.8.
Plaintext Encryption with AES Cipher Block Chaining (CBC) Mode
4.9.
Plaintext Encryption with AES Galois/Counter Mode (GCM)
4.10.
Integrity Calculation with HMAC SHA256, HMAC SHA384, or HMAC SHA512
4.11.
Additional Encryption Algorithms and Parameters
5.
Cryptographic Algorithms for JWK
5.1.
"alg" (Algorithm Family) Parameter Values for JWK
5.2.
JWK Parameters for Elliptic Curve Keys
5.2.1.
"crv" (Curve) Parameter
5.2.2.
"x" (X Coordinate) Parameter
5.2.3.
"y" (Y Coordinate) Parameter
5.3.
JWK Parameters for RSA Keys
5.3.1.
"mod" (Modulus) Parameter
5.3.2.
"exp" (Exponent) Parameter
5.4.
Additional Key Algorithm Families and Parameters
6.
IANA Considerations
6.1.
JSON Web Signature and Encryption Header Parameters Registry
6.2.
JSON Web Signature and Encryption Algorithms Registry
6.3.
JSON Web Signature and Encryption "typ" Values Registry
6.4.
JSON Web Key Parameters Registry
6.5.
JSON Web Key Algorithm Families Registry
7.
Security Considerations
8.
Open Issues and Things To Be Done (TBD)
9.
References
9.1.
Normative References
9.2.
Informative References
Appendix A.
Digital Signature/MAC Algorithm Identifier CrossReference
Appendix B.
Encryption Algorithm Identifier CrossReference
Appendix C.
Acknowledgements
Appendix D.
Document History
§
Author's Address
TOC 
The JSON Web Algorithms (JWA) specification enumerates cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS) [JWS] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” May 2012.) and JSON Web Encryption (JWE) [JWE] (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” May 2012.) specifications. Enumerating the algorithms and identifiers for them in this specification, rather than in the JWS and JWE specifications, is intended to allow them to remain unchanged in the face of changes in the set of required, recommended, optional, and deprecated algorithms over time. This specification also describes the semantics and operations that are specific to these algorithms and algorithm families.
TOC 
This specification uses the terminology defined by the JSON Web Signature (JWS) [JWS] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” May 2012.) and JSON Web Encryption (JWE) [JWE] (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” May 2012.) specifications.
TOC 
JWS uses cryptographic algorithms to digitally sign or MAC the contents of the JWS Header and the JWS Payload. The use of the following algorithms for producing JWSs is defined in this section.
TOC 
The table below is the set of alg (algorithm) header parameter values defined by this specification for use with JWS, each of which is explained in more detail in the following sections:
alg Parameter Value  Digital Signature or MAC Algorithm 

HS256  HMAC using SHA256 hash algorithm 
HS384  HMAC using SHA384 hash algorithm 
HS512  HMAC using SHA512 hash algorithm 
RS256  RSA using SHA256 hash algorithm 
RS384  RSA using SHA384 hash algorithm 
RS512  RSA using SHA512 hash algorithm 
ES256  ECDSA using P256 curve and SHA256 hash algorithm 
ES384  ECDSA using P384 curve and SHA384 hash algorithm 
ES512  ECDSA using P521 curve and SHA512 hash algorithm 
none  No digital signature or MAC value included 
See Appendix A (Digital Signature/MAC Algorithm Identifier CrossReference) for a table crossreferencing the digital signature and MAC alg (algorithm) values used in this specification with the equivalent identifiers used by other standards and software packages.
Of these algorithms, only HMAC SHA256 and none MUST be implemented by conforming JWS implementations. It is RECOMMENDED that implementations also support the RSA SHA256 and ECDSA P256 SHA256 algorithms. Support for other algorithms and key sizes is OPTIONAL.
TOC 
Hashbased Message Authentication Codes (HMACs) enable one to use a secret plus a cryptographic hash function to generate a Message Authentication Code (MAC). This can be used to demonstrate that the MAC matches the hashed content, in this case the JWS Secured Input, which therefore demonstrates that whoever generated the MAC was in possession of the secret. The means of exchanging the shared key is outside the scope of this specification.
The algorithm for implementing and validating HMACs is provided in RFC 2104 (Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: KeyedHashing for Message Authentication,” February 1997.) [RFC2104]. This section defines the use of the HMAC SHA256, HMAC SHA384, and HMAC SHA512 cryptographic hash functions as defined in FIPS 1803 (National Institute of Standards and Technology, “Secure Hash Standard (SHS),” October 2008.) [FIPS.180‑3]. The alg (algorithm) header parameter values HS256, HS384, and HS512 are used in the JWS Header to indicate that the Encoded JWS Signature contains a base64url encoded HMAC value using the respective hash function.
A key of the same size as the hash output (for instance, 256 bits for HS256) or larger MUST be used with this algorithm.
The HMAC SHA256 MAC is generated as follows:
The output is the Encoded JWS Signature for that JWS.
The HMAC SHA256 MAC for a JWS is validated as follows:
Alternatively, the Encoded JWS Signature MAY be base64url decoded to produce the JWS Signature and this value can be compared with the computed HMAC value, as this comparison produces the same result as comparing the encoded values.
Securing content with the HMAC SHA384 and HMAC SHA512 algorithms is performed identically to the procedure for HMAC SHA256  just with correspondingly larger minimum key sizes and result values.
TOC 
This section defines the use of the RSASSAPKCS1v1_5 digital signature algorithm as defined in RFC 3447 (Jonsson, J. and B. Kaliski, “PublicKey Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1,” February 2003.) [RFC3447], Section 8.2 (commonly known as PKCS#1), using SHA256, SHA384, or SHA512 as the hash function. The RSASSAPKCS1v1_5 algorithm is described in FIPS 1863 (National Institute of Standards and Technology, “Digital Signature Standard (DSS),” June 2009.) [FIPS.186‑3], Section 5.5, and the SHA256, SHA384, and SHA512 cryptographic hash functions are defined in FIPS 1803 (National Institute of Standards and Technology, “Secure Hash Standard (SHS),” October 2008.) [FIPS.180‑3]. The alg (algorithm) header parameter values RS256, RS384, and RS512 are used in the JWS Header to indicate that the Encoded JWS Signature contains a base64url encoded RSA digital signature using the respective hash function.
A key of size 2048 bits or larger MUST be used with these algorithms.
Note that while Section 8 of RFC 3447 (Jonsson, J. and B. Kaliski, “PublicKey Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1,” February 2003.) [RFC3447] explicitly calls for people not to adopt RSASSAPKCS1 for new applications and instead requests that people transition to RSASSAPSS, for interoperability reasons, this specification does use RSASSAPKCS1 because it commonly implemented.
The RSA SHA256 digital signature is generated as follows:
The output is the Encoded JWS Signature for that JWS.
The RSA SHA256 digital signature for a JWS is validated as follows:
Signing with the RSA SHA384 and RSA SHA512 algorithms is performed identically to the procedure for RSA SHA256  just with correspondingly larger result values.
TOC 
The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined by FIPS 1863 (National Institute of Standards and Technology, “Digital Signature Standard (DSS),” June 2009.) [FIPS.186‑3]. ECDSA provides for the use of Elliptic Curve cryptography, which is able to provide equivalent security to RSA cryptography but using shorter key sizes and with greater processing speed. This means that ECDSA digital signatures will be substantially smaller in terms of length than equivalently strong RSA digital signatures.
This specification defines the use of ECDSA with the P256 curve and the SHA256 cryptographic hash function, ECDSA with the P384 curve and the SHA384 hash function, and ECDSA with the P521 curve and the SHA512 hash function. The P256, P384, and P521 curves are also defined in FIPS 1863. The alg (algorithm) header parameter values ES256, ES384, and ES512 are used in the JWS Header to indicate that the Encoded JWS Signature contains a base64url encoded ECDSA P256 SHA256, ECDSA P384 SHA384, or ECDSA P521 SHA512 digital signature, respectively.
A key of size 160 bits or larger MUST be used with these algorithms.
The ECDSA P256 SHA256 digital signature is generated as follows:
The output is the Encoded JWS Signature for the JWS.
The ECDSA P256 SHA256 digital signature for a JWS is validated as follows:
The ECDSA validator will then determine if the digital signature is valid, given the inputs. Note that ECDSA digital signature contains a value referred to as K, which is a random number generated for each digital signature instance. This means that two ECDSA digital signatures using exactly the same input parameters will output different signature values because their K values will be different. The consequence of this is that one must validate an ECDSA digital signature by submitting the previously specified inputs to an ECDSA validator.
Signing with the ECDSA P384 SHA384 and ECDSA P521 SHA512 algorithms is performed identically to the procedure for ECDSA P256 SHA256  just with correspondingly larger result values.
TOC 
To support use cases where the content is secured by a means other than a digital signature or MAC value, JWSs MAY also be created without them. These are called "Plaintext JWSs". Plaintext JWSs MUST use the alg value none, and are formatted identically to other JWSs, but with an empty JWS Signature value.
TOC 
Additional algorithms MAY be used to protect JWSs with corresponding alg (algorithm) header parameter values being defined to refer to them. New alg header parameter values SHOULD either be defined in the IANA JSON Web Signature and Encryption Algorithms registry Section 6.2 (JSON Web Signature and Encryption Algorithms Registry) or be a URI that contains a collision resistant namespace. In particular, it is permissible to use the algorithm identifiers defined in XML DSIG (Eastlake, D., Reagle, J., and D. Solo, “(Extensible Markup Language) XMLSignature Syntax and Processing,” March 2002.) [RFC3275], XML DSIG 2.0 (Eastlake, D., Reagle, J., Yiu, K., Solo, D., Datta, P., Hirsch, F., Cantor, S., and T. Roessler, “XML Signature Syntax and Processing Version 2.0,” January 2012.) [W3C.CR‑xmldsig‑core2‑20120124], and related specifications as alg values.
As indicated by the common registry, JWSs and JWEs share a common alg value space. The values used by the two specifications MUST be distinct, as the alg value MAY be used to determine whether the object is a JWS or JWE.
Likewise, additional reserved header parameter names MAY be defined via the IANA JSON Web Signature and Encryption Header Parameters registry Section 6.1 (JSON Web Signature and Encryption Header Parameters Registry). As indicated by the common registry, JWSs and JWEs share a common header parameter space; when a parameter is used by both specifications, its usage must be compatible between the specifications.
TOC 
JWE uses cryptographic algorithms to encrypt the Content Master Key (CMK) and the Plaintext. This section specifies a set of specific algorithms for these purposes.
TOC 
The table below is the set of alg (algorithm) header parameter values that are defined by this specification for use with JWE. These algorithms are used to encrypt the CMK, producing the JWE Encrypted Key, or to use key agreement to agree upon the CMK.
TOC 
The table below is the set of enc (encryption method) header parameter values that are defined by this specification for use with JWE. These algorithms are used to encrypt the Plaintext, which produces the Ciphertext.
See Appendix B (Encryption Algorithm Identifier CrossReference) for a table crossreferencing the encryption alg (algorithm) and enc (encryption method) values used in this specification with the equivalent identifiers used by other standards and software packages.
Of these alg and enc algorithms, only RSAPKCS11.5 with 2048 bit keys, AES128KW, AES256KW, AES128CBC, and AES256CBC MUST be implemented by conforming JWE implementations. It is RECOMMENDED that implementations also support ECDHES with 256 bit keys, AES128GCM, and AES256GCM. Support for other algorithms and key sizes is OPTIONAL.
TOC 
The table below is the set of int (integrity algorithm) header parameter values defined by this specification for use with JWE. Note that these are the HMAC SHA subset of the alg (algorithm) header parameter values defined for use with JWS Section 3.1 ("alg" (Algorithm) Header Parameter Values for JWS). />
int Parameter Value  Algorithm 

HS256  HMAC using SHA256 hash algorithm 
HS384  HMAC using SHA384 hash algorithm 
HS512  HMAC using SHA512 hash algorithm 
Of these int algorithms, only HMAC SHA256 MUST be implemented by conforming JWE implementations. It is RECOMMENDED that implementations also support the RSA SHA256 and ECDSA P256 SHA256 algorithms.
TOC 
This section defines the specifics of encrypting a JWE CMK with RSA using RSAPKCS11.5 padding, as defined in RFC 3447 (Jonsson, J. and B. Kaliski, “PublicKey Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1,” February 2003.) [RFC3447]. The alg header parameter value RSA1_5 is used in this case.
A key of size 2048 bits or larger MUST be used with this algorithm.
TOC 
This section defines the specifics of encrypting a JWE CMK with RSA using Optimal Asymmetric Encryption Padding (OAEP), as defined in RFC 3447 (Jonsson, J. and B. Kaliski, “PublicKey Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1,” February 2003.) [RFC3447]. The alg header parameter value RSAOAEP is used in this case.
A key of size 2048 bits or larger MUST be used with this algorithm.
TOC 
This section defines the specifics of agreeing upon a JWE CMK with Elliptic Curve DiffieHellman Ephemeral Static, as defined in RFC 6090 (McGrew, D., Igoe, K., and M. Salter, “Fundamental Elliptic Curve Cryptography Algorithms,” February 2011.) [RFC6090], and using the Concat KDF, as defined in Section 5.8.1 of [NIST.800‑56A] (National Institute of Standards and Technology (NIST), “Recommendation for PairWise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised),” March 2007.), where the Digest Method is SHA256 and all OtherInfo parameters are the empty bit string. The alg header parameter value ECDHES is used in this case.
A key of size 160 bits or larger MUST be used for the Elliptic Curve keys used with this algorithm. The output of the Concat KDF MUST be a key of the same length as that used by the enc algorithm.
An epk (ephemeral public key) value MUST only be used for a single key agreement transaction.
TOC 
This section defines the specifics of encrypting a JWE CMK with the Advanced Encryption Standard (AES) Key Wrap Algorithm using 128 or 256 bit keys, as defined in RFC 3394 (Schaad, J. and R. Housley, “Advanced Encryption Standard (AES) Key Wrap Algorithm,” September 2002.) [RFC3394]. The alg header parameter values A128KW or A256KW are used in this case.
TOC 
This section defines the specifics of encrypting the JWE Plaintext with Advanced Encryption Standard (AES) in Cipher Block Chaining (CBC) mode using PKCS #5 padding using 128 or 256 bit keys, as defined in [FIPS.197] (National Institute of Standards and Technology (NIST), “Advanced Encryption Standard (AES),” November 2001.) and [NIST.800‑38A] (National Institute of Standards and Technology (NIST), “Recommendation for Block Cipher Modes of Operation,” December 2001.). The enc header parameter values A128CBC or A256CBC are used in this case.
Use of an Initialization Vector (IV) of size 128 bits is RECOMMENDED with this algorithm.
TOC 
This section defines the specifics of encrypting the JWE Plaintext with Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) using 128 or 256 bit keys, as defined in [FIPS.197] (National Institute of Standards and Technology (NIST), “Advanced Encryption Standard (AES),” November 2001.) and [NIST.800‑38D] (National Institute of Standards and Technology (NIST), “Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC,” December 2001.). The enc header parameter values A128GCM or A256GCM are used in this case.
Use of an Initialization Vector (IV) of size 96 bits is REQUIRED with this algorithm.
The "additional authenticated data" parameter value for the encryption is the concatenation of the Encoded JWE Header, a period ('.') character, and the Encoded JWE Encrypted Key.
The requested size of the "authentication tag" output MUST be the same as the key size (for instance, 128 bits for A128GCM).
As GCM is an AEAD algorithm, the JWE Integrity Value is set to be the "authentication tag" value produced by the encryption.
TOC 
This section defines the specifics of computing a JWE Integrity Value with HMAC SHA256, HMAC SHA384, or HMAC SHA512 as defined in FIPS 1803 (National Institute of Standards and Technology, “Secure Hash Standard (SHS),” October 2008.) [FIPS.180‑3]. The int header parameter values HS256, HS384, or HS512 are used in this case.
A key of the same size as the hash output (for instance, 256 bits for HS256) or larger MUST be used with this algorithm.
TOC 
Additional algorithms MAY be used to protect JWEs with corresponding alg (algorithm), enc (encryption method), and int (integrity algorithm) header parameter values being defined to refer to them. New alg, enc, and int header parameter values SHOULD either be defined in the IANA JSON Web Signature and Encryption Algorithms registry Section 6.2 (JSON Web Signature and Encryption Algorithms Registry) or be a URI that contains a collision resistant namespace. In particular, it is permissible to use the algorithm identifiers defined in XML Encryption (Eastlake, D. and J. Reagle, “XML Encryption Syntax and Processing,” December 2002.) [W3C.REC‑xmlenc‑core‑20021210], XML Encryption 1.1 (Eastlake, D., Reagle, J., Roessler, T., and F. Hirsch, “XML Encryption Syntax and Processing Version 1.1,” March 2012.) [W3C.CR‑xmlenc‑core1‑20120313], and related specifications as alg, enc, and int values.
As indicated by the common registry, JWSs and JWEs share a common alg value space. The values used by the two specifications MUST be distinct, as the alg value MAY be used to determine whether the object is a JWS or JWE.
Likewise, additional reserved header parameter names MAY be defined via the IANA JSON Web Signature and Encryption Header Parameters registry Section 6.1 (JSON Web Signature and Encryption Header Parameters Registry). As indicated by the common registry, JWSs and JWEs share a common header parameter space; when a parameter is used by both specifications, its usage must be compatible between the specifications.
TOC 
A JSON Web Key (JWK) [JWK] (Jones, M., “JSON Web Key (JWK),” May 2012.) is a JSON data structure that represents a public key. A JSON Web Key Set (JWK Set) is a JSON data structure for representing a set of JWKs. This section specifies a set of algorithm families to be used for those public keys and the algorithm family specific parameters for representing those keys.
TOC 
The table below is the set of alg (algorithm family) parameter values that are defined by this specification for use in JWKs.
alg Parameter Value  Algorithm Family 

EC  Elliptic Curve [FIPS.186‑3] (National Institute of Standards and Technology, “Digital Signature Standard (DSS),” June 2009.) key family 
RSA  RSA [RFC3447] (Jonsson, J. and B. Kaliski, “PublicKey Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1,” February 2003.) key family 
TOC 
JWKs can represent Elliptic Curve [FIPS.186‑3] (National Institute of Standards and Technology, “Digital Signature Standard (DSS),” June 2009.) keys. In this case, the alg member value MUST be EC. Furthermore, these additional members MUST be present:
TOC 
The crv (curve) member identifies the cryptographic curve used with the key. Values defined by this specification are P256, P384 and P521. Additional crv values MAY be used, provided they are understood by implementations using that Elliptic Curve key. The crv value is case sensitive. Its value MUST be a string.
TOC 
The x (x coordinate) member contains the x coordinate for the elliptic curve point. It is represented as the base64url encoding of the coordinate's big endian representation.
TOC 
The y (y coordinate) member contains the y coordinate for the elliptic curve point. It is represented as the base64url encoding of the coordinate's big endian representation.
TOC 
JWKs can represent RSA [RFC3447] (Jonsson, J. and B. Kaliski, “PublicKey Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1,” February 2003.) keys. In this case, the alg member value MUST be RSA. Furthermore, these additional members MUST be present:
TOC 
The mod (modulus) member contains the modulus value for the RSA public key. It is represented as the base64url encoding of the value's big endian representation.
TOC 
The exp (exponent) member contains the exponent value for the RSA public key. It is represented as the base64url encoding of the value's big endian representation.
TOC 
Public keys using additional algorithm families MAY be represented using JWK data structures with corresponding alg (algorithm family) parameter values being defined to refer to them. New alg parameter values SHOULD either be defined in the IANA JSON Web Key Algorithm Families registry Section 6.5 (JSON Web Key Algorithm Families Registry) or be a URI that contains a collision resistant namespace.
Likewise, parameters for representing keys for additional algorithm families or additional key properties SHOULD either be defined in the IANA JSON Web Key Parameters registry Section 6.4 (JSON Web Key Parameters Registry) or be a URI that contains a collision resistant namespace.
TOC 
TOC 
This specification establishes the IANA JSON Web Signature and Encryption Header Parameters registry for reserved JWS and JWE header parameter names. Inclusion in the registry is RFC Required in the RFC 5226 (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) [RFC5226] sense. The registry records the reserved header parameter name and a reference to the RFC that defines it. This specification registers the header parameter names defined in JSON Web Signature (JWS) [JWS] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” May 2012.), Section 4.1 and JSON Web Encryption (JWE) [JWE] (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” May 2012.), Section 4.1.
TOC 
This specification establishes the IANA JSON Web Signature and Encryption Algorithms registry for values of the JWS and JWE alg (algorithm), enc (encryption method), and int (integrity algorithm) header parameters. Inclusion in the registry is RFC Required in the RFC 5226 (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) [RFC5226] sense. The registry records the algorithm usage alg, enc, or int, the value, and a pointer to the RFC that defines it. This specification registers the values defined in Section 3.1 ("alg" (Algorithm) Header Parameter Values for JWS), Section 4.1 ("alg" (Algorithm) Header Parameter Values for JWE), Section 4.2 ("enc" (Encryption Method) Header Parameter Values for JWE), and Section 4.3 ("int" (Integrity Algorithm) Header Parameter Values for JWE).
TOC 
This specification establishes the IANA JSON Web Signature and Encryption "typ" Values registry for values of the JWS and JWE typ (type) header parameter. Inclusion in the registry is RFC Required in the RFC 5226 (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) [RFC5226] sense. It is RECOMMENDED that all registered typ values also register a MIME Media Type RFC 2045 (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” November 1996.) [RFC2045] that the registered value is a short name for. The registry records the typ value, the MIME type value that it is an abbreviation for (if any), and a pointer to the RFC that defines it.
MIME Media Type RFC 2045 (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” November 1996.) [RFC2045] values MUST NOT be directly registered as new typ values; rather, new typ values MAY be registered as short names for MIME types.
TOC 
This specification establishes the IANA JSON Web Key Parameters registry for reserved JWK parameter names. Inclusion in the registry is RFC Required in the RFC 5226 (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) [RFC5226] sense. The registry records the reserved parameter name and a reference to the RFC that defines it. This specification registers the parameter names defined in JSON Web Key (JWK) [JWK] (Jones, M., “JSON Web Key (JWK),” May 2012.), Section 4.2, JSON Web Encryption (JWE) [JWE] (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” May 2012.), Section 4.1, Section 5.2 (JWK Parameters for Elliptic Curve Keys), and Section 5.3 (JWK Parameters for RSA Keys).
TOC 
This specification establishes the IANA JSON Web Key Algorithm Families registry for values of the JWK alg (algorithm family) parameter. Inclusion in the registry is RFC Required in the RFC 5226 (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) [RFC5226] sense. The registry records the alg value and a pointer to the RFC that defines it. This specification registers the values defined in Section 5.1 ("alg" (Algorithm Family) Parameter Values for JWK).
TOC 
The security considerations in the JWS, JWE, and JWK specifications also apply to this specification.
Eventually the algorithms and/or key sizes currently described in this specification will no longer be considered sufficiently secure and will be removed. Therefore, implementers and deployments must be prepared for this eventuality.
TOC 
The following items remain to be done in this draft:
TOC 
TOC 
TOC 
[CanvasApp]  Facebook, “Canvas Applications,” 2010. 
[ID.rescorlajsms]  Rescorla, E. and J. Hildebrand, “JavaScript Message Security Format,” draftrescorlajsms00 (work in progress), March 2011 (TXT). 
[JCA]  Oracle, “Java Cryptography Architecture,” 2011. 
[JSE]  Bradley, J. and N. Sakimura (editor), “JSON Simple Encryption,” September 2010. 
[JSS]  Bradley, J. and N. Sakimura (editor), “JSON Simple Sign,” September 2010. 
[MagicSignatures]  Panzer (editor), J., Laurie, B., and D. Balfanz, “Magic Signatures,” January 2011. 
[RFC3275]  Eastlake, D., Reagle, J., and D. Solo, “(Extensible Markup Language) XMLSignature Syntax and Processing,” RFC 3275, March 2002 (TXT). 
[W3C.CRxmldsigcore220120124]  Eastlake, D., Reagle, J., Yiu, K., Solo, D., Datta, P., Hirsch, F., Cantor, S., and T. Roessler, “XML Signature Syntax and Processing Version 2.0,” World Wide Web Consortium CR CRxmldsigcore220120124, January 2012 (HTML). 
[W3C.CRxmlenccore120120313]  Eastlake, D., Reagle, J., Roessler, T., and F. Hirsch, “XML Encryption Syntax and Processing Version 1.1,” World Wide Web Consortium CR CRxmlenccore120120313, March 2012 (HTML). 
[W3C.RECxmlenccore20021210]  Eastlake, D. and J. Reagle, “XML Encryption Syntax and Processing,” World Wide Web Consortium Recommendation RECxmlenccore20021210, December 2002 (HTML). 
TOC 
This appendix contains a table crossreferencing the digital signature and MAC alg (algorithm) values used in this specification with the equivalent identifiers used by other standards and software packages. See XML DSIG (Eastlake, D., Reagle, J., and D. Solo, “(Extensible Markup Language) XMLSignature Syntax and Processing,” March 2002.) [RFC3275], XML DSIG 2.0 (Eastlake, D., Reagle, J., Yiu, K., Solo, D., Datta, P., Hirsch, F., Cantor, S., and T. Roessler, “XML Signature Syntax and Processing Version 2.0,” January 2012.) [W3C.CR‑xmldsig‑core2‑20120124], and Java Cryptography Architecture (Oracle, “Java Cryptography Architecture,” 2011.) [JCA] for more information about the names defined by those documents.
Algorithm  JWS  XML DSIG  JCA  OID 

HMAC using SHA256 hash algorithm  HS256  http://www.w3.org/2001/04/xmldsigmore#hmacsha256  HmacSHA256  1.2.840.113549.2.9 
HMAC using SHA384 hash algorithm  HS384  http://www.w3.org/2001/04/xmldsigmore#hmacsha384  HmacSHA384  1.2.840.113549.2.10 
HMAC using SHA512 hash algorithm  HS512  http://www.w3.org/2001/04/xmldsigmore#hmacsha512  HmacSHA512  1.2.840.113549.2.11 
RSA using SHA256 hash algorithm  RS256  http://www.w3.org/2001/04/xmldsigmore#rsasha256  SHA256withRSA  1.2.840.113549.1.1.11 
RSA using SHA384 hash algorithm  RS384  http://www.w3.org/2001/04/xmldsigmore#rsasha384  SHA384withRSA  1.2.840.113549.1.1.12 
RSA using SHA512 hash algorithm  RS512  http://www.w3.org/2001/04/xmldsigmore#rsasha512  SHA512withRSA  1.2.840.113549.1.1.13 
ECDSA using P256 curve and SHA256 hash algorithm  ES256  http://www.w3.org/2001/04/xmldsigmore#ecdsasha256  SHA256withECDSA  1.2.840.10045.4.3.2 
ECDSA using P384 curve and SHA384 hash algorithm  ES384  http://www.w3.org/2001/04/xmldsigmore#ecdsasha384  SHA384withECDSA  1.2.840.10045.4.3.3 
ECDSA using P521 curve and SHA512 hash algorithm  ES512  http://www.w3.org/2001/04/xmldsigmore#ecdsasha512  SHA512withECDSA  1.2.840.10045.4.3.4 
TOC 
This appendix contains a table crossreferencing the alg (algorithm) and enc (encryption method) values used in this specification with the equivalent identifiers used by other standards and software packages. See XML Encryption (Eastlake, D. and J. Reagle, “XML Encryption Syntax and Processing,” December 2002.) [W3C.REC‑xmlenc‑core‑20021210], XML Encryption 1.1 (Eastlake, D., Reagle, J., Roessler, T., and F. Hirsch, “XML Encryption Syntax and Processing Version 1.1,” March 2012.) [W3C.CR‑xmlenc‑core1‑20120313], and Java Cryptography Architecture (Oracle, “Java Cryptography Architecture,” 2011.) [JCA] for more information about the names defined by those documents.
Algorithm  JWE  XML ENC  JCA 

RSA using RSAPKCS11.5 padding  RSA1_5  http://www.w3.org/2001/04/xmlenc#rsa1_5  RSA/ECB/PKCS1Padding 
RSA using Optimal Asymmetric Encryption Padding (OAEP)  RSAOAEP  http://www.w3.org/2001/04/xmlenc#rsaoaepmgf1p  RSA/ECB/OAEPWithSHA1AndMGF1Padding 
Elliptic Curve DiffieHellman Ephemeral Static  ECDHES  http://www.w3.org/2009/xmlenc11#ECDHES  TBD 
Advanced Encryption Standard (AES) Key Wrap Algorithm RFC 3394 (Schaad, J. and R. Housley, “Advanced Encryption Standard (AES) Key Wrap Algorithm,” September 2002.) [RFC3394] using 128 bit keys  A128KW  http://www.w3.org/2001/04/xmlenc#kwaes128  TBD 
Advanced Encryption Standard (AES) Key Wrap Algorithm RFC 3394 (Schaad, J. and R. Housley, “Advanced Encryption Standard (AES) Key Wrap Algorithm,” September 2002.) [RFC3394] using 256 bit keys  A256KW  http://www.w3.org/2001/04/xmlenc#kwaes256  TBD 
Advanced Encryption Standard (AES) using 128 bit keys in Cipher Block Chaining (CBC) mode using PKCS #5 padding  A128CBC  http://www.w3.org/2001/04/xmlenc#aes128cbc  AES/CBC/PKCS5Padding 
Advanced Encryption Standard (AES) using 256 bit keys in Cipher Block Chaining (CBC) mode using PKCS #5 padding  A256CBC  http://www.w3.org/2001/04/xmlenc#aes256cbc  AES/CBC/PKCS5Padding 
Advanced Encryption Standard (AES) using 128 bit keys in Galois/Counter Mode (GCM)  A128GCM  http://www.w3.org/2009/xmlenc11#aes128gcm  AES/GCM/NoPadding 
Advanced Encryption Standard (AES) using 256 bit keys in Galois/Counter Mode (GCM)  A256GCM  http://www.w3.org/2009/xmlenc11#aes256gcm  AES/GCM/NoPadding 
TOC 
Solutions for signing and encrypting JSON content were previously explored by Magic Signatures (Panzer (editor), J., Laurie, B., and D. Balfanz, “Magic Signatures,” January 2011.) [MagicSignatures], JSON Simple Sign (Bradley, J. and N. Sakimura (editor), “JSON Simple Sign,” September 2010.) [JSS], Canvas Applications (Facebook, “Canvas Applications,” 2010.) [CanvasApp], JSON Simple Encryption (Bradley, J. and N. Sakimura (editor), “JSON Simple Encryption,” September 2010.) [JSE], and JavaScript Message Security Format (Rescorla, E. and J. Hildebrand, “JavaScript Message Security Format,” March 2011.) [I‑D.rescorla‑jsms], all of which influenced this draft. Dirk Balfanz, John Bradley, Yaron Y. Goland, John Panzer, Nat Sakimura, and Paul Tarjan all made significant contributions to the design of this specification and its related specifications.
TOC 
02
01
00
TOC 
Michael B. Jones  
Microsoft  
Email:  mbj@microsoft.com 
URI:  http://selfissued.info/ 