draft-ietf-jose-json-web-algorithms-01.txt | draft-ietf-jose-json-web-algorithms-02.txt | |||
---|---|---|---|---|

JOSE Working Group M. Jones | JOSE Working Group M. Jones | |||

Internet-Draft Microsoft | Internet-Draft Microsoft | |||

Intended status: Standards Track March 12, 2012 | Intended status: Standards Track May 12, 2012 | |||

Expires: September 13, 2012 | Expires: November 13, 2012 | |||

JSON Web Algorithms (JWA) | JSON Web Algorithms (JWA) | |||

draft-ietf-jose-json-web-algorithms-01 | draft-ietf-jose-json-web-algorithms-02 | |||

Abstract | Abstract | |||

The JSON Web Algorithms (JWA) specification enumerates cryptographic | The JSON Web Algorithms (JWA) specification enumerates cryptographic | |||

algorithms and identifiers to be used with the JSON Web Signature | algorithms and identifiers to be used with the JSON Web Signature | |||

(JWS) and JSON Web Encryption (JWE) specifications. | (JWS) and JSON Web Encryption (JWE) specifications. | |||

Requirements Language | Requirements Language | |||

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||

skipping to change at page 1, line 38 | skipping to change at page 1, line 38 | |||

Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||

Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||

working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||

Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||

Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||

and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||

time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||

material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||

This Internet-Draft will expire on September 13, 2012. | This Internet-Draft will expire on November 13, 2012. | |||

Copyright Notice | Copyright Notice | |||

Copyright (c) 2012 IETF Trust and the persons identified as the | Copyright (c) 2012 IETF Trust and the persons identified as the | |||

document authors. All rights reserved. | document authors. All rights reserved. | |||

This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||

Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||

(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||

publication of this document. Please review these documents | publication of this document. Please review these documents | |||

carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||

to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||

include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||

the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||

described in the Simplified BSD License. | described in the Simplified BSD License. | |||

Table of Contents | Table of Contents | |||

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||

2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||

3. Cryptographic Algorithms for JWS . . . . . . . . . . . . . . . 3 | 3. Cryptographic Algorithms for JWS . . . . . . . . . . . . . . . 4 | |||

3.1. Creating a JWS with HMAC SHA-256, HMAC SHA-384, or | 3.1. "alg" (Algorithm) Header Parameter Values for JWS . . . . 4 | |||

HMAC SHA-512 . . . . . . . . . . . . . . . . . . . . . . . 4 | 3.2. MAC with HMAC SHA-256, HMAC SHA-384, or HMAC SHA-512 . . . 5 | |||

3.2. Creating a JWS with RSA SHA-256, RSA SHA-384, or RSA | 3.3. Digital Signature with RSA SHA-256, RSA SHA-384, or | |||

SHA-512 . . . . . . . . . . . . . . . . . . . . . . . . . 5 | RSA SHA-512 . . . . . . . . . . . . . . . . . . . . . . . 6 | |||

3.3. Creating a JWS with ECDSA P-256 SHA-256, ECDSA P-384 | 3.4. Digital Signature with ECDSA P-256 SHA-256, ECDSA | |||

SHA-384, or ECDSA P-521 SHA-512 . . . . . . . . . . . . . 6 | P-384 SHA-384, or ECDSA P-521 SHA-512 . . . . . . . . . . 7 | |||

3.4. Creating a Plaintext JWS . . . . . . . . . . . . . . . . . 7 | 3.5. Creating a Plaintext JWS . . . . . . . . . . . . . . . . . 9 | |||

3.5. Additional Digital Signature/HMAC Algorithms . . . . . . . 7 | 3.6. Additional Digital Signature/MAC Algorithms and | |||

4. Cryptographic Algorithms for JWE . . . . . . . . . . . . . . . 8 | Parameters . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||

4.1. Encrypting a JWE with TBD . . . . . . . . . . . . . . . . 9 | 4. Cryptographic Algorithms for JWE . . . . . . . . . . . . . . . 9 | |||

4.2. Additional Encryption Algorithms . . . . . . . . . . . . . 9 | 4.1. "alg" (Algorithm) Header Parameter Values for JWE . . . . 9 | |||

5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 4.2. "enc" (Encryption Method) Header Parameter Values for | |||

6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | JWE . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||

7. Open Issues and Things To Be Done (TBD) . . . . . . . . . . . 10 | 4.3. "int" (Integrity Algorithm) Header Parameter Values | |||

8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | for JWE . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||

8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 | 4.4. Key Encryption with RSA using RSA-PKCS1-1.5 Padding . . . 11 | |||

8.2. Informative References . . . . . . . . . . . . . . . . . . 12 | 4.5. Key Encryption with RSA using Optimal Asymmetric | |||

Appendix A. Digital Signature/HMAC Algorithm Identifier | Encryption Padding (OAEP) . . . . . . . . . . . . . . . . 11 | |||

Cross-Reference . . . . . . . . . . . . . . . . . . . 13 | 4.6. Key Agreement with Elliptic Curve Diffie-Hellman | |||

Appendix B. Encryption Algorithm Identifier Cross-Reference . . . 15 | Ephemeral Static (ECDH-ES) . . . . . . . . . . . . . . . . 12 | |||

Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 19 | 4.7. Key Encryption with AES Key Wrap . . . . . . . . . . . . . 12 | |||

Appendix D. Document History . . . . . . . . . . . . . . . . . . 19 | 4.8. Plaintext Encryption with AES Cipher Block Chaining | |||

Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 | (CBC) Mode . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||

4.9. Plaintext Encryption with AES Galois/Counter Mode (GCM) . 12 | ||||

4.10. Integrity Calculation with HMAC SHA-256, HMAC SHA-384, | ||||

or HMAC SHA-512 . . . . . . . . . . . . . . . . . . . . . 13 | ||||

4.11. Additional Encryption Algorithms and Parameters . . . . . 13 | ||||

5. Cryptographic Algorithms for JWK . . . . . . . . . . . . . . . 13 | ||||

5.1. "alg" (Algorithm Family) Parameter Values for JWK . . . . 14 | ||||

5.2. JWK Parameters for Elliptic Curve Keys . . . . . . . . . . 14 | ||||

5.2.1. "crv" (Curve) Parameter . . . . . . . . . . . . . . . 14 | ||||

5.2.2. "x" (X Coordinate) Parameter . . . . . . . . . . . . . 14 | ||||

5.2.3. "y" (Y Coordinate) Parameter . . . . . . . . . . . . . 14 | ||||

5.3. JWK Parameters for RSA Keys . . . . . . . . . . . . . . . 14 | ||||

5.3.1. "mod" (Modulus) Parameter . . . . . . . . . . . . . . 15 | ||||

5.3.2. "exp" (Exponent) Parameter . . . . . . . . . . . . . . 15 | ||||

5.4. Additional Key Algorithm Families and Parameters . . . . . 15 | ||||

6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | ||||

6.1. JSON Web Signature and Encryption Header Parameters | ||||

Registry . . . . . . . . . . . . . . . . . . . . . . . . . 15 | ||||

6.2. JSON Web Signature and Encryption Algorithms Registry . . 15 | ||||

6.3. JSON Web Signature and Encryption "typ" Values Registry . 16 | ||||

6.4. JSON Web Key Parameters Registry . . . . . . . . . . . . . 16 | ||||

6.5. JSON Web Key Algorithm Families Registry . . . . . . . . . 16 | ||||

7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | ||||

8. Open Issues and Things To Be Done (TBD) . . . . . . . . . . . 17 | ||||

9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | ||||

9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 | ||||

9.2. Informative References . . . . . . . . . . . . . . . . . . 18 | ||||

Appendix A. Digital Signature/MAC Algorithm Identifier | ||||

Cross-Reference . . . . . . . . . . . . . . . . . . . 19 | ||||

Appendix B. Encryption Algorithm Identifier Cross-Reference . . . 21 | ||||

Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 25 | ||||

Appendix D. Document History . . . . . . . . . . . . . . . . . . 25 | ||||

Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 | ||||

1. Introduction | 1. Introduction | |||

The JSON Web Algorithms (JWA) specification enumerates cryptographic | The JSON Web Algorithms (JWA) specification enumerates cryptographic | |||

algorithms and identifiers to be used with the JSON Web Signature | algorithms and identifiers to be used with the JSON Web Signature | |||

(JWS) [JWS] and JSON Web Encryption (JWE) [JWE] specifications. | (JWS) [JWS] and JSON Web Encryption (JWE) [JWE] specifications. | |||

Enumerating the algorithms and identifiers for them in this | Enumerating the algorithms and identifiers for them in this | |||

specification, rather than in the JWS and JWE specifications, is | specification, rather than in the JWS and JWE specifications, is | |||

intended to allow them to remain unchanged in the face of changes in | intended to allow them to remain unchanged in the face of changes in | |||

the set of required, recommended, optional, and deprecated algorithms | the set of required, recommended, optional, and deprecated algorithms | |||

skipping to change at page 3, line 26 | skipping to change at page 4, line 26 | |||

families. | families. | |||

2. Terminology | 2. Terminology | |||

This specification uses the terminology defined by the JSON Web | This specification uses the terminology defined by the JSON Web | |||

Signature (JWS) [JWS] and JSON Web Encryption (JWE) [JWE] | Signature (JWS) [JWS] and JSON Web Encryption (JWE) [JWE] | |||

specifications. | specifications. | |||

3. Cryptographic Algorithms for JWS | 3. Cryptographic Algorithms for JWS | |||

JWS uses cryptographic algorithms to sign the contents of the JWS | JWS uses cryptographic algorithms to digitally sign or MAC the | |||

Header and the JWS Payload. The use of the following algorithms for | contents of the JWS Header and the JWS Payload. The use of the | |||

producing JWSs is defined in this section. | following algorithms for producing JWSs is defined in this section. | |||

The table below Table 1 is the set of "alg" (algorithm) header | 3.1. "alg" (Algorithm) Header Parameter Values for JWS | |||

parameter values defined by this specification for use with JWS, each | ||||

of which is explained in more detail in the following sections: | 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 | Algorithm | | | alg Parameter | Digital Signature or MAC Algorithm | | |||

| Value | | | | Value | | | |||

+--------------------+----------------------------------------------+ | +--------------------+----------------------------------------------+ | |||

| HS256 | HMAC using SHA-256 hash algorithm | | | HS256 | HMAC using SHA-256 hash algorithm | | |||

| HS384 | HMAC using SHA-384 hash algorithm | | | HS384 | HMAC using SHA-384 hash algorithm | | |||

| HS512 | HMAC using SHA-512 hash algorithm | | | HS512 | HMAC using SHA-512 hash algorithm | | |||

| RS256 | RSA using SHA-256 hash algorithm | | | RS256 | RSA using SHA-256 hash algorithm | | |||

| RS384 | RSA using SHA-384 hash algorithm | | | RS384 | RSA using SHA-384 hash algorithm | | |||

| RS512 | RSA using SHA-512 hash algorithm | | | RS512 | RSA using SHA-512 hash algorithm | | |||

| ES256 | ECDSA using P-256 curve and SHA-256 hash | | | ES256 | ECDSA using P-256 curve and SHA-256 hash | | |||

| | algorithm | | | | algorithm | | |||

| ES384 | ECDSA using P-384 curve and SHA-384 hash | | | ES384 | ECDSA using P-384 curve and SHA-384 hash | | |||

| | algorithm | | | | algorithm | | |||

| ES512 | ECDSA using P-521 curve and SHA-512 hash | | | ES512 | ECDSA using P-521 curve and SHA-512 hash | | |||

| | algorithm | | | | algorithm | | |||

| none | No digital signature or HMAC value included | | | none | No digital signature or MAC value included | | |||

+--------------------+----------------------------------------------+ | +--------------------+----------------------------------------------+ | |||

Table 1: JWS Defined "alg" Parameter Values | ||||

See Appendix A for a table cross-referencing the digital signature | See Appendix A for a table cross-referencing the digital signature | |||

and HMAC "alg" (algorithm) values used in this specification with the | and MAC "alg" (algorithm) values used in this specification with the | |||

equivalent identifiers used by other standards and software packages. | equivalent identifiers used by other standards and software packages. | |||

Of these algorithms, only HMAC SHA-256 and "none" MUST be implemented | Of these algorithms, only HMAC SHA-256 and "none" MUST be implemented | |||

by conforming JWS implementations. It is RECOMMENDED that | by conforming JWS implementations. It is RECOMMENDED that | |||

implementations also support the RSA SHA-256 and ECDSA P-256 SHA-256 | implementations also support the RSA SHA-256 and ECDSA P-256 SHA-256 | |||

algorithms. Support for other algorithms and key sizes is OPTIONAL. | algorithms. Support for other algorithms and key sizes is OPTIONAL. | |||

3.1. Creating a JWS with HMAC SHA-256, HMAC SHA-384, or HMAC SHA-512 | 3.2. MAC with HMAC SHA-256, HMAC SHA-384, or HMAC SHA-512 | |||

Hash based Message Authentication Codes (HMACs) enable one to use a | Hash-based Message Authentication Codes (HMACs) enable one to use a | |||

secret plus a cryptographic hash function to generate a Message | secret plus a cryptographic hash function to generate a Message | |||

Authentication Code (MAC). This can be used to demonstrate that the | Authentication Code (MAC). This can be used to demonstrate that the | |||

MAC matches the hashed content, in this case the JWS Secured Input, | MAC matches the hashed content, in this case the JWS Secured Input, | |||

which therefore demonstrates that whoever generated the MAC was in | which therefore demonstrates that whoever generated the MAC was in | |||

possession of the secret. The means of exchanging the shared key is | possession of the secret. The means of exchanging the shared key is | |||

outside the scope of this specification. | outside the scope of this specification. | |||

The algorithm for implementing and validating HMACs is provided in | The algorithm for implementing and validating HMACs is provided in | |||

RFC 2104 [RFC2104]. This section defines the use of the HMAC SHA- | RFC 2104 [RFC2104]. This section defines the use of the HMAC SHA- | |||

256, HMAC SHA-384, and HMAC SHA-512 cryptographic hash functions as | 256, HMAC SHA-384, and HMAC SHA-512 cryptographic hash functions as | |||

defined in FIPS 180-3 [FIPS.180-3]. The "alg" (algorithm) header | defined in FIPS 180-3 [FIPS.180-3]. The "alg" (algorithm) header | |||

parameter values "HS256", "HS384", and "HS512" are used in the JWS | parameter values "HS256", "HS384", and "HS512" are used in the JWS | |||

Header to indicate that the Encoded JWS Signature contains a | Header to indicate that the Encoded JWS Signature contains a | |||

base64url encoded HMAC value using the respective hash function. | 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 SHA-256 MAC is generated as follows: | The HMAC SHA-256 MAC is generated as follows: | |||

1. Apply the HMAC SHA-256 algorithm to the UTF-8 representation of | 1. Apply the HMAC SHA-256 algorithm to the bytes of the UTF-8 | |||

the JWS Secured Input using the shared key to produce an HMAC | representation of the JWS Secured Input (which is the same as the | |||

ASCII representation) using the shared key to produce an HMAC | ||||

value. | value. | |||

2. Base64url encode the resulting HMAC value. | 2. Base64url encode the resulting HMAC value. | |||

The output is the Encoded JWS Signature for that JWS. | The output is the Encoded JWS Signature for that JWS. | |||

The HMAC SHA-256 MAC for a JWS is validated as follows: | The HMAC SHA-256 MAC for a JWS is validated as follows: | |||

1. Apply the HMAC SHA-256 algorithm to the UTF-8 representation of | 1. Apply the HMAC SHA-256 algorithm to the bytes of the UTF-8 | |||

the JWS Secured Input of the JWS using the shared key. | representation of the JWS Secured Input (which is the same as the | |||

ASCII representation) of the JWS using the shared key. | ||||

2. Base64url encode the resulting HMAC value. | 2. Base64url encode the resulting HMAC value. | |||

3. If the Encoded JWS Signature and the base64url encoded HMAC value | 3. If the Encoded JWS Signature and the base64url encoded HMAC value | |||

exactly match, then one has confirmation that the shared key was | exactly match, then one has confirmation that the shared key was | |||

used to generate the HMAC on the JWS and that the contents of the | used to generate the HMAC on the JWS and that the contents of the | |||

JWS have not be tampered with. | JWS have not be tampered with. | |||

4. If the validation fails, the JWS MUST be rejected. | 4. If the validation fails, the JWS MUST be rejected. | |||

Alternatively, the Encoded JWS Signature MAY be base64url decoded to | Alternatively, the Encoded JWS Signature MAY be base64url decoded to | |||

produce the JWS Signature and this value can be compared with the | produce the JWS Signature and this value can be compared with the | |||

computed HMAC value, as this comparison produces the same result as | computed HMAC value, as this comparison produces the same result as | |||

comparing the encoded values. | comparing the encoded values. | |||

Securing content with the HMAC SHA-384 and HMAC SHA-512 algorithms is | Securing content with the HMAC SHA-384 and HMAC SHA-512 algorithms is | |||

performed identically to the procedure for HMAC SHA-256 - just with | performed identically to the procedure for HMAC SHA-256 - just with | |||

correspondingly longer minimum key sizes and result values. | correspondingly larger minimum key sizes and result values. | |||

3.2. Creating a JWS with RSA SHA-256, RSA SHA-384, or RSA SHA-512 | 3.3. Digital Signature with RSA SHA-256, RSA SHA-384, or RSA SHA-512 | |||

This section defines the use of the RSASSA-PKCS1-v1_5 digital | This section defines the use of the RSASSA-PKCS1-v1_5 digital | |||

signature algorithm as defined in RFC 3447 [RFC3447], Section 8.2 | signature algorithm as defined in RFC 3447 [RFC3447], Section 8.2 | |||

(commonly known as PKCS#1), using SHA-256, SHA-384, or SHA-512 as the | (commonly known as PKCS#1), using SHA-256, SHA-384, or SHA-512 as the | |||

hash function. The RSASSA-PKCS1-v1_5 algorithm is described in FIPS | hash function. The RSASSA-PKCS1-v1_5 algorithm is described in FIPS | |||

186-3 [FIPS.186-3], Section 5.5, and the SHA-256, SHA-384, and SHA- | 186-3 [FIPS.186-3], Section 5.5, and the SHA-256, SHA-384, and SHA- | |||

512 cryptographic hash functions are defined in FIPS 180-3 | 512 cryptographic hash functions are defined in FIPS 180-3 | |||

[FIPS.180-3]. The "alg" (algorithm) header parameter values "RS256", | [FIPS.180-3]. The "alg" (algorithm) header parameter values "RS256", | |||

"RS384", and "RS512" are used in the JWS Header to indicate that the | "RS384", and "RS512" are used in the JWS Header to indicate that the | |||

Encoded JWS Signature contains a base64url encoded RSA digital | Encoded JWS Signature contains a base64url encoded RSA digital | |||

signature using the respective hash function. | signature using the respective hash function. | |||

A 2048-bit or longer key length MUST be used with this algorithm. | A key of size 2048 bits or larger MUST be used with these algorithms. | |||

Note that while Section 8 of RFC 3447 [RFC3447] explicitly calls for | ||||

people not to adopt RSASSA-PKCS1 for new applications and instead | ||||

requests that people transition to RSASSA-PSS, for interoperability | ||||

reasons, this specification does use RSASSA-PKCS1 because it commonly | ||||

implemented. | ||||

The RSA SHA-256 digital signature is generated as follows: | The RSA SHA-256 digital signature is generated as follows: | |||

1. Generate a digital signature of the UTF-8 representation of the | 1. Generate a digital signature of the bytes of the UTF-8 | |||

JWS Secured Input using RSASSA-PKCS1-V1_5-SIGN and the SHA-256 | representation of the JWS Secured Input (which is the same as the | |||

hash function with the desired private key. The output will be a | ASCII representation) using RSASSA-PKCS1-V1_5-SIGN and the SHA- | |||

byte array. | 256 hash function with the desired private key. The output will | |||

be a byte array. | ||||

2. Base64url encode the resulting byte array. | 2. Base64url encode the resulting byte array. | |||

The output is the Encoded JWS Signature for that JWS. | The output is the Encoded JWS Signature for that JWS. | |||

The RSA SHA-256 digital signature for a JWS is validated as follows: | The RSA SHA-256 digital signature for a JWS is validated as follows: | |||

1. Take the Encoded JWS Signature and base64url decode it into a | 1. Take the Encoded JWS Signature and base64url decode it into a | |||

byte array. If decoding fails, the JWS MUST be rejected. | byte array. If decoding fails, the JWS MUST be rejected. | |||

2. Submit the UTF-8 representation of the JWS Secured Input and the | 2. Submit the bytes of the UTF-8 representation of the JWS Secured | |||

Input (which is the same as the ASCII representation) and the | ||||

public key corresponding to the private key used by the signer to | public key corresponding to the private key used by the signer to | |||

the RSASSA-PKCS1-V1_5-VERIFY algorithm using SHA-256 as the hash | the RSASSA-PKCS1-V1_5-VERIFY algorithm using SHA-256 as the hash | |||

function. | function. | |||

3. If the validation fails, the JWS MUST be rejected. | 3. If the validation fails, the JWS MUST be rejected. | |||

Signing with the RSA SHA-384 and RSA SHA-512 algorithms is performed | Signing with the RSA SHA-384 and RSA SHA-512 algorithms is performed | |||

identically to the procedure for RSA SHA-256 - just with | identically to the procedure for RSA SHA-256 - just with | |||

correspondingly longer minimum key sizes and result values. | correspondingly larger result values. | |||

3.3. Creating a JWS with ECDSA P-256 SHA-256, ECDSA P-384 SHA-384, or | 3.4. Digital Signature with ECDSA P-256 SHA-256, ECDSA P-384 SHA-384, | |||

ECDSA P-521 SHA-512 | or ECDSA P-521 SHA-512 | |||

The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined by | The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined by | |||

FIPS 186-3 [FIPS.186-3]. ECDSA provides for the use of Elliptic | FIPS 186-3 [FIPS.186-3]. ECDSA provides for the use of Elliptic | |||

Curve cryptography, which is able to provide equivalent security to | Curve cryptography, which is able to provide equivalent security to | |||

RSA cryptography but using shorter key lengths and with greater | RSA cryptography but using shorter key sizes and with greater | |||

processing speed. This means that ECDSA digital signatures will be | processing speed. This means that ECDSA digital signatures will be | |||

substantially smaller in terms of length than equivalently strong RSA | substantially smaller in terms of length than equivalently strong RSA | |||

digital signatures. | digital signatures. | |||

This specification defines the use of ECDSA with the P-256 curve and | This specification defines the use of ECDSA with the P-256 curve and | |||

the SHA-256 cryptographic hash function, ECDSA with the P-384 curve | the SHA-256 cryptographic hash function, ECDSA with the P-384 curve | |||

and the SHA-384 hash function, and ECDSA with the P-521 curve and the | and the SHA-384 hash function, and ECDSA with the P-521 curve and the | |||

SHA-512 hash function. The P-256, P-384, and P-521 curves are also | SHA-512 hash function. The P-256, P-384, and P-521 curves are also | |||

defined in FIPS 186-3. The "alg" (algorithm) header parameter values | defined in FIPS 186-3. The "alg" (algorithm) header parameter values | |||

"ES256", "ES384", and "ES512" are used in the JWS Header to indicate | "ES256", "ES384", and "ES512" are used in the JWS Header to indicate | |||

that the Encoded JWS Signature contains a base64url encoded ECDSA | that the Encoded JWS Signature contains a base64url encoded ECDSA | |||

P-256 SHA-256, ECDSA P-384 SHA-384, or ECDSA P-521 SHA-512 digital | P-256 SHA-256, ECDSA P-384 SHA-384, or ECDSA P-521 SHA-512 digital | |||

signature, respectively. | signature, respectively. | |||

A key of size 160 bits or larger MUST be used with these algorithms. | ||||

The ECDSA P-256 SHA-256 digital signature is generated as follows: | The ECDSA P-256 SHA-256 digital signature is generated as follows: | |||

1. Generate a digital signature of the UTF-8 representation of the | 1. Generate a digital signature of the bytes of the UTF-8 | |||

JWS Secured Input using ECDSA P-256 SHA-256 with the desired | representation of the JWS Secured Input (which is the same as the | |||

ASCII representation) using ECDSA P-256 SHA-256 with the desired | ||||

private key. The output will be the EC point (R, S), where R and | private key. The output will be the EC point (R, S), where R and | |||

S are unsigned integers. | S are unsigned integers. | |||

2. Turn R and S into byte arrays in big endian order. Each array | 2. Turn R and S into byte arrays in big endian order. Each array | |||

will be 32 bytes long. | will be 32 bytes long. | |||

3. Concatenate the two byte arrays in the order R and then S. | 3. Concatenate the two byte arrays in the order R and then S. | |||

4. Base64url encode the resulting 64 byte array. | 4. Base64url encode the resulting 64 byte array. | |||

skipping to change at page 7, line 14 | skipping to change at page 8, line 29 | |||

The ECDSA P-256 SHA-256 digital signature for a JWS is validated as | The ECDSA P-256 SHA-256 digital signature for a JWS is validated as | |||

follows: | follows: | |||

1. Take the Encoded JWS Signature and base64url decode it into a | 1. Take the Encoded JWS Signature and base64url decode it into a | |||

byte array. If decoding fails, the JWS MUST be rejected. | byte array. If decoding fails, the JWS MUST be rejected. | |||

2. The output of the base64url decoding MUST be a 64 byte array. | 2. The output of the base64url decoding MUST be a 64 byte array. | |||

3. Split the 64 byte array into two 32 byte arrays. The first array | 3. Split the 64 byte array into two 32 byte arrays. The first array | |||

will be R and the second S. Remember that the byte arrays are in | will be R and the second S (with both being in big endian byte | |||

big endian byte order; please check the ECDSA validator in use to | order). | |||

see what byte order it requires. | ||||

4. Submit the UTF-8 representation of the JWS Secured Input, R, S | 4. Submit the bytes of the UTF-8 representation of the JWS Secured | |||

and the public key (x, y) to the ECDSA P-256 SHA-256 validator. | Input (which is the same as the ASCII representation), R, S and | |||

the public key (x, y) to the ECDSA P-256 SHA-256 validator. | ||||

5. If the validation fails, the JWS MUST be rejected. | 5. If the validation fails, the JWS MUST be rejected. | |||

The ECDSA validator will then determine if the digital signature is | The ECDSA validator will then determine if the digital signature is | |||

valid, given the inputs. Note that ECDSA digital signature contains | valid, given the inputs. Note that ECDSA digital signature contains | |||

a value referred to as K, which is a random number generated for each | a value referred to as K, which is a random number generated for each | |||

digital signature instance. This means that two ECDSA digital | digital signature instance. This means that two ECDSA digital | |||

signatures using exactly the same input parameters will output | signatures using exactly the same input parameters will output | |||

different signature values because their K values will be different. | different signature values because their K values will be different. | |||

The consequence of this is that one must validate an ECDSA digital | The consequence of this is that one must validate an ECDSA digital | |||

signature by submitting the previously specified inputs to an ECDSA | signature by submitting the previously specified inputs to an ECDSA | |||

validator. | validator. | |||

Signing with the ECDSA P-384 SHA-384 and ECDSA P-521 SHA-512 | Signing with the ECDSA P-384 SHA-384 and ECDSA P-521 SHA-512 | |||

algorithms is performed identically to the procedure for ECDSA P-256 | algorithms is performed identically to the procedure for ECDSA P-256 | |||

SHA-256 - just with correspondingly longer minimum key sizes and | SHA-256 - just with correspondingly larger result values. | |||

result values. | ||||

3.4. Creating a Plaintext JWS | 3.5. Creating a Plaintext JWS | |||

To support use cases where the content is secured by a means other | 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 | than a digital signature or MAC value, JWSs MAY also be created | |||

without them. These are called "Plaintext JWSs". Plaintext JWSs | without them. These are called "Plaintext JWSs". Plaintext JWSs | |||

MUST use the "alg" value "none", and are formatted identically to | MUST use the "alg" value "none", and are formatted identically to | |||

other JWSs, but with an empty JWS Signature value. | other JWSs, but with an empty JWS Signature value. | |||

3.5. Additional Digital Signature/HMAC Algorithms | 3.6. Additional Digital Signature/MAC Algorithms and Parameters | |||

Additional algorithms MAY be used to protect JWSs with corresponding | Additional algorithms MAY be used to protect JWSs with corresponding | |||

"alg" (algorithm) header parameter values being defined to refer to | "alg" (algorithm) header parameter values being defined to refer to | |||

them. New "alg" header parameter values SHOULD either be defined in | them. New "alg" header parameter values SHOULD either be defined in | |||

the IANA JSON Web Signature Algorithms registry or be a URI that | the IANA JSON Web Signature and Encryption Algorithms registry | |||

contains a collision resistant namespace. In particular, it is | Section 6.2 or be a URI that contains a collision resistant | |||

permissible to use the algorithm identifiers defined in XML DSIG | namespace. In particular, it is permissible to use the algorithm | |||

[RFC3275] and related specifications as "alg" values. | identifiers defined in XML DSIG [RFC3275], XML DSIG 2.0 | |||

[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. 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. | ||||

4. Cryptographic Algorithms for JWE | 4. Cryptographic Algorithms for JWE | |||

JWE uses cryptographic algorithms to encrypt the Content Encryption | JWE uses cryptographic algorithms to encrypt the Content Master Key | |||

Key (CEK) and the Plaintext. This section specifies a set of | (CMK) and the Plaintext. This section specifies a set of specific | |||

specific algorithms for these purposes. | algorithms for these purposes. | |||

The table below Table 2 is the set of "alg" (algorithm) header | 4.1. "alg" (Algorithm) Header Parameter Values for JWE | |||

parameter values that are defined by this specification for use with | ||||

JWE. These algorithms are used to encrypt the CEK, which produces | The table below is the set of "alg" (algorithm) header parameter | |||

the JWE Encrypted Key. | 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. | ||||

+-----------+-------------------------------------------------------+ | +-----------+-------------------------------------------------------+ | |||

| alg | Encryption Algorithm | | | alg | Key Encryption or Agreement Algorithm | | |||

| Parameter | | | | Parameter | | | |||

| Value | | | | Value | | | |||

+-----------+-------------------------------------------------------+ | +-----------+-------------------------------------------------------+ | |||

| RSA1_5 | RSA using RSA-PKCS1-1.5 padding, as defined in RFC | | | RSA1_5 | RSA using RSA-PKCS1-1.5 padding, as defined in RFC | | |||

| | 3447 [RFC3447] | | | | 3447 [RFC3447] | | |||

| RSA-OAEP | RSA using Optimal Asymmetric Encryption Padding | | | RSA-OAEP | RSA using Optimal Asymmetric Encryption Padding | | |||

| | (OAEP), as defined in RFC 3447 [RFC3447] | | | | (OAEP), as defined in RFC 3447 [RFC3447] | | |||

| ECDH-ES | Elliptic Curve Diffie-Hellman Ephemeral Static, as | | | ECDH-ES | Elliptic Curve Diffie-Hellman Ephemeral Static, as | | |||

| | defined in RFC 6090 [RFC6090], and using the Concat | | | | defined in RFC 6090 [RFC6090], and using the Concat | | |||

| | KDF, as defined in [NIST-800-56A], where the Digest | | | | KDF, as defined in Section 5.8.1 of [NIST.800-56A], | | |||

| | Method is SHA-256 and all OtherInfo parameters are | | | | where the Digest Method is SHA-256 and all OtherInfo | | |||

| | the empty bit string | | | | parameters are the empty bit string | | |||

| A128KW | Advanced Encryption Standard (AES) Key Wrap Algorithm | | | A128KW | Advanced Encryption Standard (AES) Key Wrap Algorithm | | |||

| | using 128 bit keys, as defined in RFC 3394 [RFC3394] | | | | using 128 bit keys, as defined in RFC 3394 [RFC3394] | | |||

| A256KW | Advanced Encryption Standard (AES) Key Wrap Algorithm | | | A256KW | Advanced Encryption Standard (AES) Key Wrap Algorithm | | |||

| | using 256 bit keys, as defined in RFC 3394 [RFC3394] | | | | using 256 bit keys, as defined in RFC 3394 [RFC3394] | | |||

| A512KW | Advanced Encryption Standard (AES) Key Wrap Algorithm | | ||||

| | using 512 bit keys, as defined in RFC 3394 [RFC3394] | | ||||

| A128GCM | Advanced Encryption Standard (AES) using 128 bit keys | | ||||

| | in Galois/Counter Mode, as defined in [FIPS-197] and | | ||||

| | [NIST-800-38D] | | ||||

| A256GCM | Advanced Encryption Standard (AES) using 256 bit keys | | ||||

| | in Galois/Counter Mode, as defined in [FIPS-197] and | | ||||

| | [NIST-800-38D] | | ||||

+-----------+-------------------------------------------------------+ | +-----------+-------------------------------------------------------+ | |||

Table 2: JWE Defined "alg" Parameter Values | 4.2. "enc" (Encryption Method) Header Parameter Values for JWE | |||

The table below Table 3 is the set of "enc" (encryption method) | The table below is the set of "enc" (encryption method) header | |||

header parameter values that are defined by this specification for | parameter values that are defined by this specification for use with | |||

use with JWE. These algorithms are used to encrypt the Plaintext, | JWE. These algorithms are used to encrypt the Plaintext, which | |||

which produces the Ciphertext. | produces the Ciphertext. | |||

+-----------+-------------------------------------------------------+ | +-----------+-------------------------------------------------------+ | |||

| enc | Symmetric Encryption Algorithm | | | enc | Block Encryption Algorithm | | |||

| Parameter | | | | Parameter | | | |||

| Value | | | | Value | | | |||

+-----------+-------------------------------------------------------+ | +-----------+-------------------------------------------------------+ | |||

| A128CBC | Advanced Encryption Standard (AES) using 128 bit keys | | | A128CBC | Advanced Encryption Standard (AES) using 128 bit keys | | |||

| | in Cipher Block Chaining mode, as defined in | | | | in Cipher Block Chaining (CBC) mode using PKCS #5 | | |||

| | [FIPS-197] and [NIST-800-38A] | | | | padding, as defined in [FIPS.197] and [NIST.800-38A] | | |||

| A256CBC | Advanced Encryption Standard (AES) using 256 bit keys | | | A256CBC | Advanced Encryption Standard (AES) using 256 bit keys | | |||

| | in Cipher Block Chaining mode, as defined in | | | | in Cipher Block Chaining (CBC) mode using PKCS #5 | | |||

| | [FIPS-197] and [NIST-800-38A] | | | | padding, as defined in [FIPS.197] and [NIST.800-38A] | | |||

| A128GCM | Advanced Encryption Standard (AES) using 128 bit keys | | | A128GCM | Advanced Encryption Standard (AES) using 128 bit keys | | |||

| | in Galois/Counter Mode, as defined in [FIPS-197] and | | | | in Galois/Counter Mode (GCM), as defined in | | |||

| | [NIST-800-38D] | | | | [FIPS.197] and [NIST.800-38D] | | |||

| A256GCM | Advanced Encryption Standard (AES) using 256 bit keys | | | A256GCM | Advanced Encryption Standard (AES) using 256 bit keys | | |||

| | in Galois/Counter Mode, as defined in [FIPS-197] and | | | | in Galois/Counter Mode (GCM), as defined in | | |||

| | [NIST-800-38D] | | | | [FIPS.197] and [NIST.800-38D] | | |||

+-----------+-------------------------------------------------------+ | +-----------+-------------------------------------------------------+ | |||

Table 3: JWE Defined "enc" Parameter Values | ||||

See Appendix B for a table cross-referencing the encryption "alg" | See Appendix B for a table cross-referencing the encryption "alg" | |||

(algorithm) and "enc" (encryption method) values used in this | (algorithm) and "enc" (encryption method) values used in this | |||

specification with the equivalent identifiers used by other standards | specification with the equivalent identifiers used by other standards | |||

and software packages. | and software packages. | |||

Of these algorithms, only RSA-PKCS1-1.5 with 2048 bit keys, AES-128- | Of these "alg" and "enc" algorithms, only RSA-PKCS1-1.5 with 2048 bit | |||

CBC, and AES-256-CBC MUST be implemented by conforming JWE | keys, AES-128-KW, AES-256-KW, AES-128-CBC, and AES-256-CBC MUST be | |||

implementations. It is RECOMMENDED that implementations also support | implemented by conforming JWE implementations. It is RECOMMENDED | |||

ECDH-ES with 256 bit keys, AES-128-GCM, and AES-256-GCM. Support for | that implementations also support ECDH-ES with 256 bit keys, AES-128- | |||

other algorithms and key sizes is OPTIONAL. | GCM, and AES-256-GCM. Support for other algorithms and key sizes is | |||

OPTIONAL. | ||||

4.1. Encrypting a JWE with TBD | 4.3. "int" (Integrity Algorithm) Header Parameter Values for JWE | |||

TBD: Descriptions of the particulars of using each specified | The table below is the set of "int" (integrity algorithm) header | |||

encryption algorithm go here. | 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. /> | ||||

4.2. Additional Encryption Algorithms | +---------------------+-----------------------------------+ | |||

| int Parameter Value | Algorithm | | ||||

+---------------------+-----------------------------------+ | ||||

| HS256 | HMAC using SHA-256 hash algorithm | | ||||

| HS384 | HMAC using SHA-384 hash algorithm | | ||||

| HS512 | HMAC using SHA-512 hash algorithm | | ||||

+---------------------+-----------------------------------+ | ||||

Of these "int" algorithms, only HMAC SHA-256 MUST be implemented by | ||||

conforming JWE implementations. It is RECOMMENDED that | ||||

implementations also support the RSA SHA-256 and ECDSA P-256 SHA-256 | ||||

algorithms. | ||||

4.4. Key Encryption with RSA using RSA-PKCS1-1.5 Padding | ||||

This section defines the specifics of encrypting a JWE CMK with RSA | ||||

using RSA-PKCS1-1.5 padding, as defined in RFC 3447 [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. | ||||

4.5. Key Encryption with RSA using Optimal Asymmetric Encryption | ||||

Padding (OAEP) | ||||

This section defines the specifics of encrypting a JWE CMK with RSA | ||||

using Optimal Asymmetric Encryption Padding (OAEP), as defined in RFC | ||||

3447 [RFC3447]. The "alg" header parameter value "RSA-OAEP" is used | ||||

in this case. | ||||

A key of size 2048 bits or larger MUST be used with this algorithm. | ||||

4.6. Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static | ||||

(ECDH-ES) | ||||

This section defines the specifics of agreeing upon a JWE CMK with | ||||

Elliptic Curve Diffie-Hellman Ephemeral Static, as defined in RFC | ||||

6090 [RFC6090], and using the Concat KDF, as defined in Section 5.8.1 | ||||

of [NIST.800-56A], where the Digest Method is SHA-256 and all | ||||

OtherInfo parameters are the empty bit string. The "alg" header | ||||

parameter value "ECDH-ES" 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. | ||||

4.7. Key Encryption with AES Key Wrap | ||||

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 [RFC3394]. The "alg" header | ||||

parameter values "A128KW" or "A256KW" are used in this case. | ||||

4.8. Plaintext Encryption with AES Cipher Block Chaining (CBC) Mode | ||||

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] and [NIST.800-38A]. 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. | ||||

4.9. Plaintext Encryption with AES Galois/Counter Mode (GCM) | ||||

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] and | ||||

[NIST.800-38D]. 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. | ||||

4.10. Integrity Calculation with HMAC SHA-256, HMAC SHA-384, or HMAC | ||||

SHA-512 | ||||

This section defines the specifics of computing a JWE Integrity Value | ||||

with HMAC SHA-256, HMAC SHA-384, or HMAC SHA-512 as defined in FIPS | ||||

180-3 [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. | ||||

4.11. Additional Encryption Algorithms and Parameters | ||||

Additional algorithms MAY be used to protect JWEs with corresponding | Additional algorithms MAY be used to protect JWEs with corresponding | |||

"alg" (algorithm) and "enc" (encryption method) header parameter | "alg" (algorithm), "enc" (encryption method), and "int" (integrity | |||

values being defined to refer to them. New "alg" and "enc" header | algorithm) header parameter values being defined to refer to them. | |||

parameter values SHOULD either be defined in the IANA JSON Web | New "alg", "enc", and "int" header parameter values SHOULD either be | |||

Encryption Algorithms registry or be a URI that contains a collision | defined in the IANA JSON Web Signature and Encryption Algorithms | |||

resistant namespace. In particular, it is permissible to use the | registry Section 6.2 or be a URI that contains a collision resistant | |||

algorithm identifiers defined in XML Encryption | namespace. In particular, it is permissible to use the algorithm | |||

identifiers defined in XML Encryption [W3C.REC-xmlenc-core-20021210], | ||||

XML Encryption 1.1 [W3C.CR-xmlenc-core1-20120313], and related | ||||

specifications as "alg", "enc", and "int" values. | ||||

[W3C.REC-xmlenc-core-20021210], XML Encryption 1.1 | As indicated by the common registry, JWSs and JWEs share a common | |||

[W3C.CR-xmlenc-core1-20110303], and related specifications as "alg" | "alg" value space. The values used by the two specifications MUST be | |||

and "enc" values. | distinct, as the "alg" value MAY be used to determine whether the | |||

object is a JWS or JWE. | ||||

5. IANA Considerations | Likewise, additional reserved header parameter names MAY be defined | |||

via the IANA JSON Web Signature and Encryption Header Parameters | ||||

registry Section 6.1. 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. | ||||

This specification calls for: | 5. Cryptographic Algorithms for JWK | |||

o A new IANA registry entitled "JSON Web Signature Algorithms" for | A JSON Web Key (JWK) [JWK] is a JSON data structure that represents a | |||

values of the JWS "alg" (algorithm) header parameter is defined in | public key. A JSON Web Key Set (JWK Set) is a JSON data structure | |||

Section 3.5. Inclusion in the registry is RFC Required in the RFC | for representing a set of JWKs. This section specifies a set of | |||

5226 [RFC5226] sense. The registry will just record the "alg" | algorithm families to be used for those public keys and the algorithm | |||

value and a pointer to the RFC that defines it. This | family specific parameters for representing those keys. | |||

specification defines inclusion of the algorithm values defined in | ||||

Table 1. | ||||

o A new IANA registry entitled "JSON Web Encryption Algorithms" for | 5.1. "alg" (Algorithm Family) Parameter Values for JWK | |||

values used with the JWE "alg" (algorithm) and "enc" (encryption | ||||

method) header parameters is defined in Section 4.2. Inclusion in | ||||

the registry is RFC Required in the RFC 5226 [RFC5226] sense. The | ||||

registry will record the "alg" or "enc" value and a pointer to the | ||||

RFC that defines it. This specification defines inclusion of the | ||||

algorithm values defined in Table 2 and Table 3. | ||||

6. Security Considerations | The table below is the set of "alg" (algorithm family) parameter | |||

values that are defined by this specification for use in JWKs. | ||||

TBD | +---------------------+----------------------------------------+ | |||

| alg Parameter Value | Algorithm Family | | ||||

+---------------------+----------------------------------------+ | ||||

| EC | Elliptic Curve [FIPS.186-3] key family | | ||||

| RSA | RSA [RFC3447] key family | | ||||

+---------------------+----------------------------------------+ | ||||

7. Open Issues and Things To Be Done (TBD) | 5.2. JWK Parameters for Elliptic Curve Keys | |||

The following items remain to be done in this draft: | JWKs can represent Elliptic Curve [FIPS.186-3] keys. In this case, | |||

the "alg" member value MUST be "EC". Furthermore, these additional | ||||

members MUST be present: | ||||

o Specify minimum required key sizes for all algorithms. | 5.2.1. "crv" (Curve) Parameter | |||

o Specify which algorithms require Initialization Vectors (IVs) and | The "crv" (curve) member identifies the cryptographic curve used with | |||

minimum required lengths for those IVs. | the key. Values defined by this specification are "P-256", "P-384" | |||

and "P-521". 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. | ||||

o Since RFC 3447 Section 8 explicitly calls for people NOT to adopt | 5.2.2. "x" (X Coordinate) Parameter | |||

RSASSA-PKCS1 for new applications and instead requests that people | ||||

transition to RSASSA-PSS, we probably need some Security | ||||

Considerations text explaining why RSASSA-PKCS1 is being used | ||||

(it's what's commonly implemented) and what the potential | ||||

consequences are. | ||||

o Should we define the use of RFC 5649 key wrapping functions, which | The "x" (x coordinate) member contains the x coordinate for the | |||

allow arbitrary key sizes, in addition to the current use of RFC | elliptic curve point. It is represented as the base64url encoding of | |||

3394 key wrapping functions, which require that keys be multiples | the coordinate's big endian representation. | |||

of 64 bits? Is this needed in practice? | ||||

o Decide whether to move the JWK algorithm family definitions "EC" | 5.2.3. "y" (Y Coordinate) Parameter | |||

and "RSA" here. This would likely result in all the family- | ||||

specific parameter definitions also moving here ("crv", "x", "y", | ||||

"mod", "exp"), leaving very little normative text in the JWK spec | ||||

itself. This seems like it would reduce spec readability and so | ||||

was not done. | ||||

o It would be good to say somewhere, in normative language, that | The "y" (y coordinate) member contains the y coordinate for the | |||

eventually the algorithms and/or key sizes currently specified | elliptic curve point. It is represented as the base64url encoding of | |||

will no longer be considered sufficiently secure and will be | the coordinate's big endian representation. | |||

removed. Therefore, implementers MUST be prepared for this | ||||

eventuality. | ||||

o Write the Security Considerations section. | 5.3. JWK Parameters for RSA Keys | |||

8. References | JWKs can represent RSA [RFC3447] keys. In this case, the "alg" | |||

member value MUST be "RSA". Furthermore, these additional members | ||||

MUST be present: | ||||

8.1. Normative References | 5.3.1. "mod" (Modulus) Parameter | |||

[FIPS-197] | The "mod" (modulus) member contains the modulus value for the RSA | |||

National Institute of Standards and Technology (NIST), | public key. It is represented as the base64url encoding of the | |||

"Advanced Encryption Standard (AES)", FIPS PUB 197, | value's big endian representation. | |||

November 2001. | ||||

5.3.2. "exp" (Exponent) Parameter | ||||

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. | ||||

5.4. Additional Key Algorithm Families and Parameters | ||||

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 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 or be a URI that | ||||

contains a collision resistant namespace. | ||||

6. IANA Considerations | ||||

6.1. JSON Web Signature and Encryption Header Parameters Registry | ||||

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 [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], Section 4.1 and JSON Web Encryption (JWE) | ||||

[JWE], Section 4.1. | ||||

6.2. JSON Web Signature and Encryption Algorithms Registry | ||||

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 [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, Section 4.1, Section 4.2, and Section 4.3. | ||||

6.3. JSON Web Signature and Encryption "typ" Values Registry | ||||

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 [RFC5226] sense. It is RECOMMENDED that all | ||||

registered "typ" values also register a MIME Media Type RFC 2045 | ||||

[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 [RFC2045] values MUST NOT be directly | ||||

registered as new "typ" values; rather, new "typ" values MAY be | ||||

registered as short names for MIME types. | ||||

6.4. JSON Web Key Parameters Registry | ||||

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 [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], Section 4.2, JSON Web Encryption (JWE) | ||||

[JWE], Section 4.1, Section 5.2, and Section 5.3. | ||||

6.5. JSON Web Key Algorithm Families Registry | ||||

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 | ||||

[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. | ||||

7. Security Considerations | ||||

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. | ||||

8. Open Issues and Things To Be Done (TBD) | ||||

The following items remain to be done in this draft: | ||||

o Find values for encryption algorithm cross-reference table | ||||

currently listed as "TBD" or determine that they do not exist. | ||||

9. References | ||||

9.1. Normative References | ||||

[FIPS.180-3] | [FIPS.180-3] | |||

National Institute of Standards and Technology, "Secure | National Institute of Standards and Technology, "Secure | |||

Hash Standard (SHS)", FIPS PUB 180-3, October 2008. | Hash Standard (SHS)", FIPS PUB 180-3, October 2008. | |||

[FIPS.186-3] | [FIPS.186-3] | |||

National Institute of Standards and Technology, "Digital | National Institute of Standards and Technology, "Digital | |||

Signature Standard (DSS)", FIPS PUB 186-3, June 2009. | Signature Standard (DSS)", FIPS PUB 186-3, June 2009. | |||

[FIPS.197] | ||||

National Institute of Standards and Technology (NIST), | ||||

"Advanced Encryption Standard (AES)", FIPS PUB 197, | ||||

November 2001. | ||||

[JWE] Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web | [JWE] Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web | |||

Encryption (JWE)", March 2012. | Encryption (JWE)", May 2012. | |||

[JWK] Jones, M., "JSON Web Key (JWK)", May 2012. | ||||

[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web | [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web | |||

Signature (JWS)", March 2012. | Signature (JWS)", May 2012. | |||

[NIST-800-38A] | [NIST.800-38A] | |||

National Institute of Standards and Technology (NIST), | National Institute of Standards and Technology (NIST), | |||

"Recommendation for Block Cipher Modes of Operation", | "Recommendation for Block Cipher Modes of Operation", | |||

NIST PUB 800-38A, December 2001. | NIST PUB 800-38A, December 2001. | |||

[NIST-800-38D] | [NIST.800-38D] | |||

National Institute of Standards and Technology (NIST), | National Institute of Standards and Technology (NIST), | |||

"Recommendation for Block Cipher Modes of Operation: | "Recommendation for Block Cipher Modes of Operation: | |||

Galois/Counter Mode (GCM) and GMAC", NIST PUB 800-38D, | Galois/Counter Mode (GCM) and GMAC", NIST PUB 800-38D, | |||

December 2001. | December 2001. | |||

[NIST-800-56A] | [NIST.800-56A] | |||

National Institute of Standards and Technology (NIST), | National Institute of Standards and Technology (NIST), | |||

"Recommendation for Pair-Wise Key Establishment Schemes | "Recommendation for Pair-Wise Key Establishment Schemes | |||

Using Discrete Logarithm Cryptography (Revised)", NIST PUB | Using Discrete Logarithm Cryptography (Revised)", NIST PUB | |||

800-56A, March 2007. | 800-56A, March 2007. | |||

[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | ||||

Extensions (MIME) Part One: Format of Internet Message | ||||

Bodies", RFC 2045, November 1996. | ||||

[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | |||

Hashing for Message Authentication", RFC 2104, | Hashing for Message Authentication", RFC 2104, | |||

February 1997. | February 1997. | |||

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||

Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||

[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard | [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard | |||

(AES) Key Wrap Algorithm", RFC 3394, September 2002. | (AES) Key Wrap Algorithm", RFC 3394, September 2002. | |||

skipping to change at page 12, line 38 | skipping to change at page 18, line 31 | |||

Standards (PKCS) #1: RSA Cryptography Specifications | Standards (PKCS) #1: RSA Cryptography Specifications | |||

Version 2.1", RFC 3447, February 2003. | Version 2.1", RFC 3447, February 2003. | |||

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||

IANA Considerations Section in RFCs", BCP 26, RFC 5226, | IANA Considerations Section in RFCs", BCP 26, RFC 5226, | |||

May 2008. | May 2008. | |||

[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic | [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic | |||

Curve Cryptography Algorithms", RFC 6090, February 2011. | Curve Cryptography Algorithms", RFC 6090, February 2011. | |||

8.2. Informative References | 9.2. Informative References | |||

[CanvasApp] | [CanvasApp] | |||

Facebook, "Canvas Applications", 2010. | Facebook, "Canvas Applications", 2010. | |||

[I-D.rescorla-jsms] | [I-D.rescorla-jsms] | |||

Rescorla, E. and J. Hildebrand, "JavaScript Message | Rescorla, E. and J. Hildebrand, "JavaScript Message | |||

Security Format", draft-rescorla-jsms-00 (work in | Security Format", draft-rescorla-jsms-00 (work in | |||

progress), March 2011. | progress), March 2011. | |||

[JCA] Oracle, "Java Cryptography Architecture", 2011. | [JCA] Oracle, "Java Cryptography Architecture", 2011. | |||

skipping to change at page 13, line 16 | skipping to change at page 19, line 9 | |||

September 2010. | September 2010. | |||

[MagicSignatures] | [MagicSignatures] | |||

Panzer (editor), J., Laurie, B., and D. Balfanz, "Magic | Panzer (editor), J., Laurie, B., and D. Balfanz, "Magic | |||

Signatures", January 2011. | Signatures", January 2011. | |||

[RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup | [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup | |||

Language) XML-Signature Syntax and Processing", RFC 3275, | Language) XML-Signature Syntax and Processing", RFC 3275, | |||

March 2002. | March 2002. | |||

[W3C.CR-xmlenc-core1-20110303] | [W3C.CR-xmldsig-core2-20120124] | |||

Hirsch, F., Roessler, T., Reagle, J., and D. Eastlake, | 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 CR-xmldsig-core2-20120124, January 2012, | ||||

<http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124>. | ||||

[W3C.CR-xmlenc-core1-20120313] | ||||

Eastlake, D., Reagle, J., Roessler, T., and F. Hirsch, | ||||

"XML Encryption Syntax and Processing Version 1.1", World | "XML Encryption Syntax and Processing Version 1.1", World | |||

Wide Web Consortium CR CR-xmlenc-core1-20110303, | Wide Web Consortium CR CR-xmlenc-core1-20120313, | |||

March 2011, | March 2012, | |||

<http://www.w3.org/TR/2011/CR-xmlenc-core1-20110303>. | <http://www.w3.org/TR/2012/CR-xmlenc-core1-20120313>. | |||

[W3C.REC-xmlenc-core-20021210] | [W3C.REC-xmlenc-core-20021210] | |||

Eastlake, D. and J. Reagle, "XML Encryption Syntax and | Eastlake, D. and J. Reagle, "XML Encryption Syntax and | |||

Processing", World Wide Web Consortium Recommendation REC- | Processing", World Wide Web Consortium Recommendation REC- | |||

xmlenc-core-20021210, December 2002, | xmlenc-core-20021210, December 2002, | |||

<http://www.w3.org/TR/2002/REC-xmlenc-core-20021210>. | <http://www.w3.org/TR/2002/REC-xmlenc-core-20021210>. | |||

Appendix A. Digital Signature/HMAC Algorithm Identifier Cross-Reference | Appendix A. Digital Signature/MAC Algorithm Identifier Cross-Reference | |||

This appendix contains a table cross-referencing the digital | This appendix contains a table cross-referencing the digital | |||

signature and HMAC "alg" (algorithm) values used in this | signature and MAC "alg" (algorithm) values used in this specification | |||

specification with the equivalent identifiers used by other standards | with the equivalent identifiers used by other standards and software | |||

and software packages. See XML DSIG [RFC3275] and Java Cryptography | packages. See XML DSIG [RFC3275], XML DSIG 2.0 | |||

Architecture [JCA] for more information about the names defined by | [W3C.CR-xmldsig-core2-20120124], and Java Cryptography Architecture | |||

those documents. | [JCA] for more information about the names defined by those | |||

documents. | ||||

+-------+-----+----------------------------+----------+-------------+ | +-------+-----+----------------------------+----------+-------------+ | |||

| Algor | JWS | XML DSIG | JCA | OID | | | Algor | JWS | XML DSIG | JCA | OID | | |||

| ithm | | | | | | | ithm | | | | | | |||

+-------+-----+----------------------------+----------+-------------+ | +-------+-----+----------------------------+----------+-------------+ | |||

| HMAC | HS2 | http://www.w3.org/2001/04/ | HmacSHA2 | 1.2.840.113 | | | HMAC | HS2 | http://www.w3.org/2001/04/ | HmacSHA2 | 1.2.840.113 | | |||

| using | 56 | xmldsig-more#hmac-sha256 | 56 | 549.2.9 | | | using | 56 | xmldsig-more#hmac-sha256 | 56 | 549.2.9 | | |||

| SHA-2 | | | | | | | SHA-2 | | | | | | |||

| 56 | | | | | | | 56 | | | | | | |||

| hash | | | | | | | hash | | | | | | |||

skipping to change at page 15, line 36 | skipping to change at page 21, line 26 | |||

| P-521 | | | | | | | P-521 | | | | | | |||

| curve | | | | | | | curve | | | | | | |||

| and | | | | | | | and | | | | | | |||

| SHA-5 | | | | | | | SHA-5 | | | | | | |||

| 12 | | | | | | | 12 | | | | | | |||

| hash | | | | | | | hash | | | | | | |||

| algo | | | | | | | algo | | | | | | |||

| rithm | | | | | | | rithm | | | | | | |||

+-------+-----+----------------------------+----------+-------------+ | +-------+-----+----------------------------+----------+-------------+ | |||

Table 4: Digital Signature/HMAC Algorithm Identifier Cross-Reference | ||||

Appendix B. Encryption Algorithm Identifier Cross-Reference | Appendix B. Encryption Algorithm Identifier Cross-Reference | |||

This appendix contains a table cross-referencing the "alg" | This appendix contains a table cross-referencing the "alg" | |||

(algorithm) and "enc" (encryption method) values used in this | (algorithm) and "enc" (encryption method) values used in this | |||

specification with the equivalent identifiers used by other standards | specification with the equivalent identifiers used by other standards | |||

and software packages. See XML Encryption | and software packages. See XML Encryption | |||

[W3C.REC-xmlenc-core-20021210], XML Encryption 1.1 | [W3C.REC-xmlenc-core-20021210], XML Encryption 1.1 | |||

[W3C.CR-xmlenc-core1-20110303], and Java Cryptography Architecture | [W3C.CR-xmlenc-core1-20120313], and Java Cryptography Architecture | |||

[JCA] for more information about the names defined by those | [JCA] for more information about the names defined by those | |||

documents. | documents. | |||

+---------+-------+---------------------------+---------------------+ | +---------+-------+---------------------------+---------------------+ | |||

| Algorit | JWE | XML ENC | JCA | | | Algorit | JWE | XML ENC | JCA | | |||

| hm | | | | | | hm | | | | | |||

+---------+-------+---------------------------+---------------------+ | +---------+-------+---------------------------+---------------------+ | |||

| RSA | RSA1_ | http://www.w3.org/2001/04 | RSA/ECB/PKCS1Paddin | | | RSA | RSA1_ | http://www.w3.org/2001/04 | RSA/ECB/PKCS1Paddin | | |||

| using | 5 | /xmlenc#rsa-1_5 | g | | | using | 5 | /xmlenc#rsa-1_5 | g | | |||

| RSA-PKC | | | | | | RSA-PKC | | | | | |||

skipping to change at page 17, line 20 | skipping to change at page 23, line 20 | |||

| ) Key | | | | | | ) Key | | | | | |||

| Wrap | | | | | | Wrap | | | | | |||

| Algo | | | | | | Algo | | | | | |||

| rithm R | | | | | | rithm R | | | | | |||

| FC 339 | | | | | | FC 339 | | | | | |||

| 4 [RF | | | | | | 4 [RF | | | | | |||

| C3394] | | | | | | C3394] | | | | | |||

| using25 | | | | | | using25 | | | | | |||

| 6 bitke | | | | | | 6 bitke | | | | | |||

| ys | | | | | | ys | | | | | |||

| Advance | A512K | http://www.w3.org/2001/04 | TBD | | ||||

| d | W | /xmlenc#kw-aes512 | | | ||||

| Encryp | | | | | ||||

| tion | | | | | ||||

| Stand | | | | | ||||

| ard(AES | | | | | ||||

| ) Key | | | | | ||||

| Wrap | | | | | ||||

| Algo | | | | | ||||

| rithm R | | | | | ||||

| FC 339 | | | | | ||||

| 4 [RF | | | | | ||||

| C3394] | | | | | ||||

| using51 | | | | | ||||

| 2 bitke | | | | | ||||

| ys | | | | | ||||

| Advance | A128C | http://www.w3.org/2001/04 | AES/CBC/PKCS5Paddin | | | Advance | A128C | http://www.w3.org/2001/04 | AES/CBC/PKCS5Paddin | | |||

| d | BC | /xmlenc#aes128-cbc | g | | | d | BC | /xmlenc#aes128-cbc | g | | |||

| Encryp | | | | | | Encryp | | | | | |||

| tion | | | | | | tion | | | | | |||

| Stand | | | | | | Stand | | | | | |||

| ard(AES | | | | | | ard(AES | | | | | |||

| ) usin | | | | | | ) usin | | | | | |||

| g 128 | | | | | | g 128 | | | | | |||

| bitkeys | | | | | | bitkeys | | | | | |||

| inCiph | | | | | | inCiph | | | | | |||

| er Bloc | | | | | | er Bloc | | | | | |||

| k Chai | | | | | | k Chai | | | | | |||

| ningmod | | | | | | ning(CB | | | | | |||

| e | | | | | | C) mod | | | | | |||

| e usi | | | | | ||||

| ng PKC | | | | | ||||

| S #5pad | | | | | ||||

| ding | | | | | ||||

| Advance | A256C | http://www.w3.org/2001/04 | AES/CBC/PKCS5Paddin | | | Advance | A256C | http://www.w3.org/2001/04 | AES/CBC/PKCS5Paddin | | |||

| d | BC | /xmlenc#aes256-cbc | g | | | d | BC | /xmlenc#aes256-cbc | g | | |||

| Encryp | | | | | | Encryp | | | | | |||

| tion | | | | | | tion | | | | | |||

| Stand | | | | | | Stand | | | | | |||

| ard(AES | | | | | | ard(AES | | | | | |||

| ) usin | | | | | | ) usin | | | | | |||

| g 256 | | | | | | g 256 | | | | | |||

| bitkeys | | | | | | bitkeys | | | | | |||

| inCiph | | | | | | inCiph | | | | | |||

| er Bloc | | | | | | er Bloc | | | | | |||

| k Chai | | | | | | k Chai | | | | | |||

| ningmod | | | | | | ning(CB | | | | | |||

| e | | | | | | C) mod | | | | | |||

| e usi | | | | | ||||

| ng PKC | | | | | ||||

| S #5pad | | | | | ||||

| ding | | | | | ||||

| Advance | A128G | http://www.w3.org/2009/xm | AES/GCM/NoPadding | | | Advance | A128G | http://www.w3.org/2009/xm | AES/GCM/NoPadding | | |||

| d | CM | lenc11#aes128-gcm | | | | d | CM | lenc11#aes128-gcm | | | |||

| Encryp | | | | | | Encryp | | | | | |||

| tion | | | | | | tion | | | | | |||

| Stand | | | | | | Stand | | | | | |||

| ard(AES | | | | | | ard(AES | | | | | |||

| ) usin | | | | | | ) usin | | | | | |||

| g 128 | | | | | | g 128 | | | | | |||

| bitkeys | | | | | | bitkeys | | | | | |||

| inGalo | | | | | | inGalo | | | | | |||

| is/Coun | | | | | | is/Coun | | | | | |||

| ter Mod | | | | | | ter Mod | | | | | |||

| e | | | | | | e (GC | | | | | |||

| M) | | | | | ||||

| Advance | A256G | http://www.w3.org/2009/xm | AES/GCM/NoPadding | | | Advance | A256G | http://www.w3.org/2009/xm | AES/GCM/NoPadding | | |||

| d | CM | lenc11#aes256-gcm | | | | d | CM | lenc11#aes256-gcm | | | |||

| Encryp | | | | | | Encryp | | | | | |||

| tion | | | | | | tion | | | | | |||

| Stand | | | | | | Stand | | | | | |||

| ard(AES | | | | | | ard(AES | | | | | |||

| ) usin | | | | | | ) usin | | | | | |||

| g 256 | | | | | | g 256 | | | | | |||

| bitkeys | | | | | | bitkeys | | | | | |||

| inGalo | | | | | | inGalo | | | | | |||

| is/Coun | | | | | | is/Coun | | | | | |||

| ter Mod | | | | | | ter Mod | | | | | |||

| e | | | | | | e (GC | | | | | |||

| M) | | | | | ||||

+---------+-------+---------------------------+---------------------+ | +---------+-------+---------------------------+---------------------+ | |||

Table 5: Encryption Algorithm Identifier Cross-Reference | ||||

Appendix C. Acknowledgements | Appendix C. Acknowledgements | |||

Solutions for signing and encrypting JSON content were previously | Solutions for signing and encrypting JSON content were previously | |||

explored by Magic Signatures [MagicSignatures], JSON Simple Sign | explored by Magic Signatures [MagicSignatures], JSON Simple Sign | |||

[JSS], Canvas Applications [CanvasApp], JSON Simple Encryption [JSE], | [JSS], Canvas Applications [CanvasApp], JSON Simple Encryption [JSE], | |||

and JavaScript Message Security Format [I-D.rescorla-jsms], all of | and JavaScript Message Security Format [I-D.rescorla-jsms], all of | |||

which influenced this draft. Dirk Balfanz, John Bradley, Yaron Y. | which influenced this draft. Dirk Balfanz, John Bradley, Yaron Y. | |||

Goland, John Panzer, Nat Sakimura, and Paul Tarjan all made | Goland, John Panzer, Nat Sakimura, and Paul Tarjan all made | |||

significant contributions to the design of this specification and its | significant contributions to the design of this specification and its | |||

related specifications. | related specifications. | |||

Appendix D. Document History | Appendix D. Document History | |||

-02 | ||||

o For AES GCM, use the "additional authenticated data" parameter to | ||||

provide integrity for the header, encrypted key, and ciphertext | ||||

and use the resulting "authentication tag" value as the JWE | ||||

Integrity Value. | ||||

o Defined minimum required key sizes for algorithms without | ||||

specified key sizes. | ||||

o Defined KDF output key sizes. | ||||

o Specified the use of PKCS #5 padding with AES-CBC. | ||||

o Generalized text to allow key agreement to be employed as an | ||||

alternative to key wrapping or key encryption. | ||||

o Clarified that ECDH-ES is a key agreement algorithm. | ||||

o Required implementation of AES-128-KW and AES-256-KW. | ||||

o Removed the use of "A128GCM" and "A256GCM" for key wrapping. | ||||

o Removed "A512KW" since it turns out that it's not a standard | ||||

algorithm. | ||||

o Clarified the relationship between "typ" header parameter values | ||||

and MIME types. | ||||

o Generalized language to refer to Message Authentication Codes | ||||

(MACs) rather than Hash-based Message Authentication Codes (HMACs) | ||||

unless in a context specific to HMAC algorithms. | ||||

o Established registries: JSON Web Signature and Encryption Header | ||||

Parameters, JSON Web Signature and Encryption Algorithms, JSON Web | ||||

Signature and Encryption "typ" Values, JSON Web Key Parameters, | ||||

and JSON Web Key Algorithm Families. | ||||

o Moved algorithm-specific definitions from JWK to JWA. | ||||

o Reformatted to give each member definition its own section | ||||

heading. | ||||

-01 | -01 | |||

o Moved definition of "alg":"none" for JWSs here from the JWT | o Moved definition of "alg":"none" for JWSs here from the JWT | |||

specification since this functionality is likely to be useful in | specification since this functionality is likely to be useful in | |||

more contexts that just for JWTs. | more contexts that just for JWTs. | |||

o Added Advanced Encryption Standard (AES) Key Wrap Algorithm using | o Added Advanced Encryption Standard (AES) Key Wrap Algorithm using | |||

512 bit keys ("A512KW"). | 512 bit keys ("A512KW"). | |||

o Added text "Alternatively, the Encoded JWS Signature MAY be | o Added text "Alternatively, the Encoded JWS Signature MAY be | |||

End of changes. 90 change blocks. | ||||

223 lines changed or deleted | | 529 lines changed or added | ||

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |