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 September 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.
Creating a JWS with HMAC SHA256, HMAC SHA384, or HMAC SHA512
3.2.
Creating a JWS with RSA SHA256, RSA SHA384, or RSA SHA512
3.3.
Creating a JWS with ECDSA P256 SHA256, ECDSA P384 SHA384, or ECDSA P521 SHA512
3.4.
Creating a Plaintext JWS
3.5.
Additional Digital Signature/HMAC Algorithms
4.
Cryptographic Algorithms for JWE
4.1.
Encrypting a JWE with TBD
4.2.
Additional Encryption Algorithms
5.
IANA Considerations
6.
Security Considerations
7.
Open Issues and Things To Be Done (TBD)
8.
References
8.1.
Normative References
8.2.
Informative References
Appendix A.
Digital Signature/HMAC 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),” March 2012.) and JSON Web Encryption (JWE) [JWE] (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” March 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),” March 2012.) and JSON Web Encryption (JWE) [JWE] (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” March 2012.) specifications.
TOC 
JWS uses cryptographic algorithms to sign the contents of the JWS Header and the JWS Payload. The use of the following algorithms for producing JWSs is defined in this section.
The table below Table 1 (JWS Defined "alg" Parameter Values) 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  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 HMAC value included 
Table 1: JWS Defined "alg" Parameter Values 
See Appendix A (Digital Signature/HMAC Algorithm Identifier CrossReference) for a table crossreferencing the digital signature and HMAC 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 
Hash based 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.
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 longer 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 2048bit or longer key length MUST be used with this algorithm.
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 longer minimum key sizes and 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 lengths 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.
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 longer minimum key sizes and result values.
TOC 
To support use cases where the content is secured by a means other than a digital signature or HMAC 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 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] and related specifications as alg values.
TOC 
JWE uses cryptographic algorithms to encrypt the Content Encryption Key (CEK) and the Plaintext. This section specifies a set of specific algorithms for these purposes.
The table below Table 2 (JWE Defined "alg" Parameter Values) 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 CEK, which produces the JWE Encrypted Key.
Table 2: JWE Defined "alg" Parameter Values 
The table below Table 3 (JWE Defined "enc" Parameter Values) 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.
Table 3: JWE Defined "enc" Parameter Values 
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 algorithms, only RSAPKCS11.5 with 2048 bit keys, 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 
TBD: Descriptions of the particulars of using each specified encryption algorithm go here.
TOC 
Additional algorithms MAY be used to protect JWEs with corresponding alg (algorithm) and enc (encryption method) header parameter values being defined to refer to them. New alg and enc header parameter values SHOULD either be defined in the IANA JSON Web 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 (Hirsch, F., Roessler, T., Reagle, J., and D. Eastlake, “XML Encryption Syntax and Processing Version 1.1,” March 2011.) [W3C.CR‑xmlenc‑core1‑20110303], and related specifications as alg and enc values.
TOC 
This specification calls for:
TOC 
TBD
TOC 
The following items remain to be done in this draft:
TOC 
TOC 
[FIPS197]  National Institute of Standards and Technology (NIST), “Advanced Encryption Standard (AES),” FIPS PUB 197, November 2001. 
[FIPS.1803]  National Institute of Standards and Technology, “Secure Hash Standard (SHS),” FIPS PUB 1803, October 2008. 
[FIPS.1863]  National Institute of Standards and Technology, “Digital Signature Standard (DSS),” FIPS PUB 1863, June 2009. 
[JWE]  Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” March 2012. 
[JWS]  Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” March 2012. 
[NIST80038A]  National Institute of Standards and Technology (NIST), “Recommendation for Block Cipher Modes of Operation,” NIST PUB 80038A, December 2001. 
[NIST80038D]  National Institute of Standards and Technology (NIST), “Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC,” NIST PUB 80038D, December 2001. 
[NIST80056A]  National Institute of Standards and Technology (NIST), “Recommendation for PairWise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised),” NIST PUB 80056A, March 2007. 
[RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: KeyedHashing for Message Authentication,” RFC 2104, February 1997 (TXT). 
[RFC2119]  Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). 
[RFC3394]  Schaad, J. and R. Housley, “Advanced Encryption Standard (AES) Key Wrap Algorithm,” RFC 3394, September 2002 (TXT). 
[RFC3447]  Jonsson, J. and B. Kaliski, “PublicKey Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1,” RFC 3447, February 2003 (TXT). 
[RFC5226]  Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” BCP 26, RFC 5226, May 2008 (TXT). 
[RFC6090]  McGrew, D., Igoe, K., and M. Salter, “Fundamental Elliptic Curve Cryptography Algorithms,” RFC 6090, February 2011 (TXT). 
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.CRxmlenccore120110303]  Hirsch, F., Roessler, T., Reagle, J., and D. Eastlake, “XML Encryption Syntax and Processing Version 1.1,” World Wide Web Consortium CR CRxmlenccore120110303, March 2011 (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 HMAC 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] 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 
Table 4: Digital Signature/HMAC Algorithm Identifier CrossReference 
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 (Hirsch, F., Roessler, T., Reagle, J., and D. Eastlake, “XML Encryption Syntax and Processing Version 1.1,” March 2011.) [W3C.CR‑xmlenc‑core1‑20110303], 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) Key Wrap Algorithm RFC 3394 (Schaad, J. and R. Housley, “Advanced Encryption Standard (AES) Key Wrap Algorithm,” September 2002.) [RFC3394] using 512 bit keys  A512KW  http://www.w3.org/2001/04/xmlenc#kwaes512  TBD 
Advanced Encryption Standard (AES) using 128 bit keys in Cipher Block Chaining mode  A128CBC  http://www.w3.org/2001/04/xmlenc#aes128cbc  AES/CBC/PKCS5Padding 
Advanced Encryption Standard (AES) using 256 bit keys in Cipher Block Chaining mode  A256CBC  http://www.w3.org/2001/04/xmlenc#aes256cbc  AES/CBC/PKCS5Padding 
Advanced Encryption Standard (AES) using 128 bit keys in Galois/Counter Mode  A128GCM  http://www.w3.org/2009/xmlenc11#aes128gcm  AES/GCM/NoPadding 
Advanced Encryption Standard (AES) using 256 bit keys in Galois/Counter Mode  A256GCM  http://www.w3.org/2009/xmlenc11#aes256gcm  AES/GCM/NoPadding 
Table 5: Encryption Algorithm Identifier CrossReference 
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 
01
00
TOC 
Michael B. Jones  
Microsoft  
Email:  mbj@microsoft.com 
URI:  http://selfissued.info/ 