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

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

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

Intended status: Standards Track May 12, 2012 | Intended status: Standards Track July 6, 2012 | |||

Expires: November 13, 2012 | Expires: January 7, 2013 | |||

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

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

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), JSON Web Encryption (JWE), and JSON Web Key (JWK) | |||

specifications. | ||||

Requirements Language | ||||

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

Status of this Memo | Status of this Memo | |||

This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||

provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||

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 November 13, 2012. | This Internet-Draft will expire on January 7, 2013. | |||

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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||

1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4 | ||||

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

3. Cryptographic Algorithms for JWS . . . . . . . . . . . . . . . 4 | 2.1. Terms Incorporated from the JWS Specification . . . . . . 4 | |||

3.1. "alg" (Algorithm) Header Parameter Values for JWS . . . . 4 | 2.2. Terms Incorporated from the JWE Specification . . . . . . 5 | |||

3.2. MAC with HMAC SHA-256, HMAC SHA-384, or HMAC SHA-512 . . . 5 | 2.3. Terms Incorporated from the JWK Specification . . . . . . 6 | |||

2.4. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 7 | ||||

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

3.1. "alg" (Algorithm) Header Parameter Values for JWS . . . . 7 | ||||

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

3.3. Digital Signature with RSA SHA-256, RSA SHA-384, or | 3.3. Digital Signature with RSA SHA-256, RSA SHA-384, or | |||

RSA SHA-512 . . . . . . . . . . . . . . . . . . . . . . . 6 | RSA SHA-512 . . . . . . . . . . . . . . . . . . . . . . . 9 | |||

3.4. Digital Signature with ECDSA P-256 SHA-256, ECDSA | 3.4. Digital Signature with ECDSA P-256 SHA-256, ECDSA | |||

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

3.5. Creating a Plaintext JWS . . . . . . . . . . . . . . . . . 9 | 3.5. Using the Algorithm "none" . . . . . . . . . . . . . . . . 11 | |||

3.6. Additional Digital Signature/MAC Algorithms and | 3.6. Additional Digital Signature/MAC Algorithms and | |||

Parameters . . . . . . . . . . . . . . . . . . . . . . . . 9 | Parameters . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||

4. Cryptographic Algorithms for JWE . . . . . . . . . . . . . . . 9 | 4. Cryptographic Algorithms for JWE . . . . . . . . . . . . . . . 12 | |||

4.1. "alg" (Algorithm) Header Parameter Values for JWE . . . . 9 | 4.1. "alg" (Algorithm) Header Parameter Values for JWE . . . . 12 | |||

4.2. "enc" (Encryption Method) Header Parameter Values for | 4.2. "enc" (Encryption Method) Header Parameter Values for | |||

JWE . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | JWE . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||

4.3. "int" (Integrity Algorithm) Header Parameter Values | 4.3. "int" (Integrity Algorithm) Header Parameter Values | |||

for JWE . . . . . . . . . . . . . . . . . . . . . . . . . 11 | for JWE . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||

4.4. Key Encryption with RSA using RSA-PKCS1-1.5 Padding . . . 11 | 4.4. "kdf" (Key Derivation Function) Header Parameter | |||

4.5. Key Encryption with RSA using Optimal Asymmetric | Values for JWE . . . . . . . . . . . . . . . . . . . . . . 14 | |||

Encryption Padding (OAEP) . . . . . . . . . . . . . . . . 11 | 4.5. Key Encryption with RSAES-PKCS1-V1_5 . . . . . . . . . . . 15 | |||

4.6. Key Agreement with Elliptic Curve Diffie-Hellman | 4.6. Key Encryption with RSAES OAEP . . . . . . . . . . . . . . 15 | |||

Ephemeral Static (ECDH-ES) . . . . . . . . . . . . . . . . 12 | 4.7. Key Agreement with Elliptic Curve Diffie-Hellman | |||

4.7. Key Encryption with AES Key Wrap . . . . . . . . . . . . . 12 | Ephemeral Static (ECDH-ES) . . . . . . . . . . . . . . . . 15 | |||

4.8. Plaintext Encryption with AES Cipher Block Chaining | 4.8. Key Encryption with AES Key Wrap . . . . . . . . . . . . . 15 | |||

(CBC) Mode . . . . . . . . . . . . . . . . . . . . . . . . 12 | 4.9. Plaintext Encryption with AES CBC Mode . . . . . . . . . . 15 | |||

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

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

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

4.11. Additional Encryption Algorithms and Parameters . . . . . 13 | 4.12. Key Derivation with Concat KDF and SHA-256, SHA-384, | |||

5. Cryptographic Algorithms for JWK . . . . . . . . . . . . . . . 13 | or SHA-512 . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||

5.1. "alg" (Algorithm Family) Parameter Values for JWK . . . . 14 | 4.13. Additional Encryption Algorithms and Parameters . . . . . 17 | |||

5.2. JWK Parameters for Elliptic Curve Keys . . . . . . . . . . 14 | 5. Cryptographic Algorithms for JWK . . . . . . . . . . . . . . . 18 | |||

5.2.1. "crv" (Curve) Parameter . . . . . . . . . . . . . . . 14 | 5.1. "alg" (Algorithm Family) Parameter Values for JWK . . . . 18 | |||

5.2.2. "x" (X Coordinate) Parameter . . . . . . . . . . . . . 14 | 5.2. JWK Parameters for Elliptic Curve Keys . . . . . . . . . . 18 | |||

5.2.3. "y" (Y Coordinate) Parameter . . . . . . . . . . . . . 14 | 5.2.1. "crv" (Curve) Parameter . . . . . . . . . . . . . . . 18 | |||

5.3. JWK Parameters for RSA Keys . . . . . . . . . . . . . . . 14 | 5.2.2. "x" (X Coordinate) Parameter . . . . . . . . . . . . . 19 | |||

5.3.1. "mod" (Modulus) Parameter . . . . . . . . . . . . . . 15 | 5.2.3. "y" (Y Coordinate) Parameter . . . . . . . . . . . . . 19 | |||

5.3.2. "exp" (Exponent) Parameter . . . . . . . . . . . . . . 15 | 5.3. JWK Parameters for RSA Keys . . . . . . . . . . . . . . . 19 | |||

5.4. Additional Key Algorithm Families and Parameters . . . . . 15 | 5.3.1. "mod" (Modulus) Parameter . . . . . . . . . . . . . . 19 | |||

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

6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | 5.4. Additional Key Algorithm Families and Parameters . . . . . 19 | |||

6.1. JSON Web Signature and Encryption Header Parameters | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 | |||

Registry . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 6.1. JSON Web Signature and Encryption Algorithms Registry . . 20 | |||

6.2. JSON Web Signature and Encryption Algorithms Registry . . 15 | 6.1.1. Registration Template . . . . . . . . . . . . . . . . 21 | |||

6.3. JSON Web Signature and Encryption "typ" Values Registry . 16 | 6.1.2. Initial Registry Contents . . . . . . . . . . . . . . 21 | |||

6.4. JSON Web Key Parameters Registry . . . . . . . . . . . . . 16 | 6.2. JSON Web Key Algorithm Families Registry . . . . . . . . . 26 | |||

6.5. JSON Web Key Algorithm Families Registry . . . . . . . . . 16 | 6.2.1. Registration Template . . . . . . . . . . . . . . . . 26 | |||

7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | 6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 27 | |||

8. Open Issues and Things To Be Done (TBD) . . . . . . . . . . . 17 | 6.3. JSON Web Key Parameters Registration . . . . . . . . . . . 27 | |||

9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 6.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 27 | |||

9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 | |||

9.2. Informative References . . . . . . . . . . . . . . . . . . 18 | 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||

9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 | ||||

9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 | ||||

9.2. Informative References . . . . . . . . . . . . . . . . . . 31 | ||||

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

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

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

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

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

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

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

[JWK] specifications. This specification also describes the | ||||

semantics and operations that are specific to these algorithms and | ||||

algorithm families. | ||||

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, JWE, and JWK specifications, | |||

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

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

over time. This specification also describes the semantics and | algorithms over time. | |||

operations that are specific to these algorithms and algorithm | ||||

families. | 1.1. Notational Conventions | |||

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 Key words for use in | ||||

RFCs to Indicate Requirement Levels [RFC2119]. | ||||

2. Terminology | 2. Terminology | |||

This specification uses the terminology defined by the JSON Web | 2.1. Terms Incorporated from the JWS Specification | |||

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

specifications. | These terms defined by the JSON Web Signature (JWS) [JWS] | |||

specification are incorporated into this specification: | ||||

JSON Web Signature (JWS) A data structure cryptographically securing | ||||

a JWS Header and a JWS Payload with a JWS Signature value. | ||||

JWS Header A string representing a JavaScript Object Notation (JSON) | ||||

[RFC4627] object that describes the digital signature or MAC | ||||

operation applied to create the JWS Signature value. | ||||

JWS Payload The bytes to be secured - a.k.a., the message. The | ||||

payload can contain an arbitrary sequence of bytes. | ||||

JWS Signature A byte array containing the cryptographic material | ||||

that secures the contents of the JWS Header and the JWS Payload. | ||||

Encoded JWS Header Base64url encoding of the bytes of the UTF-8 | ||||

[RFC3629] representation of the JWS Header. | ||||

Encoded JWS Payload Base64url encoding of the JWS Payload. | ||||

Encoded JWS Signature Base64url encoding of the JWS Signature. | ||||

JWS Secured Input The concatenation of the Encoded JWS Header, a | ||||

period ('.') character, and the Encoded JWS Payload. | ||||

Base64url Encoding For the purposes of this specification, this term | ||||

always refers to the URL- and filename-safe Base64 encoding | ||||

described in RFC 4648 [RFC4648], Section 5, with the (non URL- | ||||

safe) '=' padding characters omitted, as permitted by Section 3.2. | ||||

(See Appendix C of [JWS] for notes on implementing base64url | ||||

encoding without padding.) | ||||

Collision Resistant Namespace A namespace that allows names to be | ||||

allocated in a manner such that they are highly unlikely to | ||||

collide with other names. For instance, collision resistance can | ||||

be achieved through administrative delegation of portions of the | ||||

namespace or through use of collision-resistant name allocation | ||||

functions. Examples of Collision Resistant Namespaces include: | ||||

Domain Names, Object Identifiers (OIDs) as defined in the ITU-T | ||||

X.660 and X.670 Recommendation series, and Universally Unique | ||||

IDentifiers (UUIDs) [RFC4122]. When using an administratively | ||||

delegated namespace, the definer of a name needs to take | ||||

reasonable precautions to ensure they are in control of the | ||||

portion of the namespace they use to define the name. | ||||

2.2. Terms Incorporated from the JWE Specification | ||||

These terms defined by the JSON Web Encryption (JWE) [JWE] | ||||

specification are incorporated into this specification: | ||||

JSON Web Encryption (JWE) A data structure representing an encrypted | ||||

version of a Plaintext. The structure consists of four parts: the | ||||

JWE Header, the JWE Encrypted Key, the JWE Ciphertext, and the JWE | ||||

Integrity Value. | ||||

Plaintext The bytes to be encrypted - a.k.a., the message. The | ||||

plaintext can contain an arbitrary sequence of bytes. | ||||

Ciphertext The encrypted version of the Plaintext. | ||||

Content Encryption Key (CEK) A symmetric key used to encrypt the | ||||

Plaintext for the recipient to produce the Ciphertext. | ||||

Content Integrity Key (CIK) A key used with a MAC function to ensure | ||||

the integrity of the Ciphertext and the parameters used to create | ||||

it. | ||||

Content Master Key (CMK) A key from which the CEK and CIK are | ||||

derived. When key wrapping or key encryption are employed, the | ||||

CMK is randomly generated and encrypted to the recipient as the | ||||

JWE Encrypted Key. When key agreement is employed, the CMK is the | ||||

result of the key agreement algorithm. | ||||

JWE Header A string representing a JSON object that describes the | ||||

encryption operations applied to create the JWE Encrypted Key, the | ||||

JWE Ciphertext, and the JWE Integrity Value. | ||||

JWE Encrypted Key When key wrapping or key encryption are employed, | ||||

the Content Master Key (CMK) is encrypted with the intended | ||||

recipient's key and the resulting encrypted content is recorded as | ||||

a byte array, which is referred to as the JWE Encrypted Key. | ||||

Otherwise, when key agreement is employed, the JWE Encrypted Key | ||||

is the empty byte array. | ||||

JWE Ciphertext A byte array containing the Ciphertext. | ||||

JWE Integrity Value A byte array containing a MAC value that ensures | ||||

the integrity of the Ciphertext and the parameters used to create | ||||

it. | ||||

Encoded JWE Header Base64url encoding of the bytes of the UTF-8 | ||||

[RFC3629] representation of the JWE Header. | ||||

Encoded JWE Encrypted Key Base64url encoding of the JWE Encrypted | ||||

Key. | ||||

Encoded JWE Ciphertext Base64url encoding of the JWE Ciphertext. | ||||

Encoded JWE Integrity Value Base64url encoding of the JWE Integrity | ||||

Value. | ||||

AEAD Algorithm An Authenticated Encryption with Associated Data | ||||

(AEAD) [RFC5116] encryption algorithm is one that provides an | ||||

integrated content integrity check. AES Galois/Counter Mode (GCM) | ||||

is one such algorithm. | ||||

2.3. Terms Incorporated from the JWK Specification | ||||

These terms defined by the JSON Web Key (JWK) [JWK] specification are | ||||

incorporated into this specification: | ||||

JSON Web Key (JWK) A JSON data structure that represents a public | ||||

key. | ||||

JSON Web Key Set (JWK Set) A JSON object that contains an array of | ||||

JWKs as a member. | ||||

2.4. Defined Terms | ||||

These terms are defined for use by this specification: | ||||

Header Parameter Name The name of a member of the JSON object | ||||

representing a JWS Header or JWE Header. | ||||

Header Parameter Value The value of a member of the JSON object | ||||

representing a JWS Header or JWE Header. | ||||

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

JWS uses cryptographic algorithms to digitally sign or MAC the | JWS uses cryptographic algorithms to digitally sign or create a | |||

contents of the JWS Header and the JWS Payload. The use of the | Message Authentication Codes (MAC) of the contents of the JWS Header | |||

following algorithms for producing JWSs is defined in this section. | and the JWS Payload. The use of the following algorithms for | |||

producing JWSs is defined in this section. | ||||

3.1. "alg" (Algorithm) Header Parameter Values for JWS | 3.1. "alg" (Algorithm) Header Parameter Values for JWS | |||

The table below is the set of "alg" (algorithm) header parameter | The table below is the set of "alg" (algorithm) header parameter | |||

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

is explained in more detail in the following sections: | is explained in more detail in the following sections: | |||

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

| alg Parameter | Digital Signature or MAC Algorithm | | | alg | Digital Signature or MAC | Implementation | | |||

| Value | | | | Parameter | Algorithm | Requirements | | |||

+--------------------+----------------------------------------------+ | | Value | | | | |||

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

| HS384 | HMAC using SHA-384 hash algorithm | | | HS256 | HMAC using SHA-256 hash | REQUIRED | | |||

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

| RS256 | RSA using SHA-256 hash algorithm | | | HS384 | HMAC using SHA-384 hash | OPTIONAL | | |||

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

| RS512 | RSA using SHA-512 hash algorithm | | | HS512 | HMAC using SHA-512 hash | OPTIONAL | | |||

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

| | algorithm | | | RS256 | RSASSA using SHA-256 hash | RECOMMENDED | | |||

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

| | algorithm | | | RS384 | RSASSA using SHA-384 hash | OPTIONAL | | |||

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

| | algorithm | | | RS512 | RSASSA using SHA-512 hash | OPTIONAL | | |||

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

+--------------------+----------------------------------------------+ | | ES256 | ECDSA using P-256 curve and | RECOMMENDED+ | | |||

| | SHA-256 hash algorithm | | | ||||

| ES384 | ECDSA using P-384 curve and | OPTIONAL | | ||||

| | SHA-384 hash algorithm | | | ||||

| ES512 | ECDSA using P-521 curve and | OPTIONAL | | ||||

| | SHA-512 hash algorithm | | | ||||

| none | No digital signature or MAC | REQUIRED | | ||||

| | value included | | | ||||

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

All the names are short because a core goal of JWS is for the | ||||

representations to be compact. However, there is no a priori length | ||||

restriction on "alg" values. | ||||

The use of "+" in the Implementation Requirements indicates that the | ||||

requirement strength is likely to be increased in a future version of | ||||

the specification. | ||||

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

and MAC "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 | ||||

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

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

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

3.2. MAC 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 functions [SHS]. The "alg" | |||

defined in FIPS 180-3 [FIPS.180-3]. The "alg" (algorithm) header | (algorithm) header parameter values "HS256", "HS384", and "HS512" are | |||

parameter values "HS256", "HS384", and "HS512" are used in the JWS | used in the JWS Header to indicate that the Encoded JWS Signature | |||

Header to indicate that the Encoded JWS Signature contains a | contains a base64url encoded HMAC value using the respective hash | |||

base64url encoded HMAC value using the respective hash function. | function. | |||

A key of the same size as the hash output (for instance, 256 bits for | A key of the same size as the hash output (for instance, 256 bits for | |||

"HS256") or larger MUST be used with this algorithm. | "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 per RFC 2104, using SHA-256 as the | |||

hash algorithm "H", using the bytes of the ASCII [USASCII] | ||||

1. Apply the HMAC SHA-256 algorithm to the bytes of the UTF-8 | representation of the JWS Secured Input as the "text" value, and | |||

representation of the JWS Secured Input (which is the same as the | using the shared key. The HMAC output value is the JWS Signature. | |||

ASCII representation) using the shared key to produce an HMAC | The JWS signature is base64url encoded to produce the Encoded JWS | |||

value. | Signature. | |||

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

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

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

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

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

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

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

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

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

Alternatively, the Encoded JWS Signature MAY be base64url decoded to | The HMAC SHA-256 MAC for a JWS is validated by computing an HMAC | |||

produce the JWS Signature and this value can be compared with the | value per RFC 2104, using SHA-256 as the hash algorithm "H", using | |||

computed HMAC value, as this comparison produces the same result as | the bytes of the ASCII representation of the received JWS Secured | |||

comparing the encoded values. | input as the "text" value, and using the shared key. This computed | |||

HMAC value is then compared to the result of base64url decoding the | ||||

received Encoded JWS signature. Alternatively, the computed HMAC | ||||

value can be base64url encoded and compared to the received Encoded | ||||

JWS Signature, as this comparison produces the same result as | ||||

comparing the unencoded values. In either case, if the values match, | ||||

the HMAC has been validated. If the validation fails, the JWS MUST | ||||

be rejected. | ||||

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

correspondingly larger minimum key sizes and result values. | the corresponding hash algorithm with correspondingly larger minimum | |||

key sizes and result values: 384 bits each for HMAC SHA-384 and 512 | ||||

bits each for HMAC SHA-512. | ||||

3.3. Digital Signature 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 Section 8.2 of RFC 3447 [RFC3447], | |||

(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 [SHS] | |||

hash function. The RSASSA-PKCS1-v1_5 algorithm is described in FIPS | as the hash functions. The "alg" (algorithm) header parameter values | |||

186-3 [FIPS.186-3], Section 5.5, and the SHA-256, SHA-384, and SHA- | "RS256", "RS384", and "RS512" are used in the JWS Header to indicate | |||

512 cryptographic hash functions are defined in FIPS 180-3 | that the Encoded JWS Signature contains a base64url encoded RSA | |||

[FIPS.180-3]. The "alg" (algorithm) header parameter values "RS256", | digital signature using the respective hash function. | |||

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

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

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

A key of size 2048 bits or larger MUST be used with these algorithms. | 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 bytes of the UTF-8 | 1. Generate a digital signature of the bytes of the ASCII | |||

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

ASCII representation) using RSASSA-PKCS1-V1_5-SIGN and the SHA- | SIGN and the SHA-256 hash function with the desired private key. | |||

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

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 bytes of the UTF-8 representation of the JWS Secured | 2. Submit the bytes of the ASCII representation of the JWS Secured | |||

Input (which is the same as the ASCII representation) and the | Input and the public key corresponding to the private key used by | |||

public key corresponding to the private key used by the signer to | the signer to the RSASSA-PKCS1-V1_5-VERIFY algorithm using SHA- | |||

the RSASSA-PKCS1-V1_5-VERIFY algorithm using SHA-256 as the hash | 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 using the | |||

correspondingly larger result values. | corresponding hash algorithm with correspondingly larger result | |||

values: 384 bits for RSA SHA-384 and 512 bits for RSA SHA-512. | ||||

3.4. Digital Signature with ECDSA P-256 SHA-256, ECDSA P-384 SHA-384, | 3.4. Digital Signature with ECDSA P-256 SHA-256, ECDSA P-384 SHA-384, | |||

or 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) [DSS] provides | |||

FIPS 186-3 [FIPS.186-3]. ECDSA provides for the use of Elliptic | for the use of Elliptic Curve cryptography, which is able to provide | |||

Curve cryptography, which is able to provide equivalent security to | equivalent security to RSA cryptography but using shorter key sizes | |||

RSA cryptography but using shorter key sizes and with greater | and with greater processing speed. This means that ECDSA digital | |||

processing speed. This means that ECDSA digital signatures will be | signatures will be substantially smaller in terms of length than | |||

substantially smaller in terms of length than equivalently strong RSA | 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 | |||

defined in FIPS 186-3. The "alg" (algorithm) header parameter values | defined in [DSS]. 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 bytes of the UTF-8 | 1. Generate a digital signature of the bytes of the ASCII | |||

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

ASCII representation) using ECDSA P-256 SHA-256 with the desired | with the desired private key. The output will be the EC point | |||

private key. The output will be the EC point (R, S), where R and | (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, with each | |||

will be 32 bytes long. | array being 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. (Note | |||

that many ECDSA implementations will directly produce this | ||||

concatenation as their output.) | ||||

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

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

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

decoding does not result in a 64 byte array, the JWS MUST be | ||||

rejected. | ||||

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 (with both being in big endian byte | will be R and the second S (with both being in big endian byte | |||

order). | order). | |||

4. Submit the bytes of the UTF-8 representation of the JWS Secured | 4. Submit the bytes of the ASCII representation of the JWS Secured | |||

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

the public key (x, y) to the ECDSA P-256 SHA-256 validator. | 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 | Note that ECDSA digital signature contains a value referred to as K, | |||

valid, given the inputs. Note that ECDSA digital signature contains | which is a random number generated for each digital signature | |||

a value referred to as K, which is a random number generated for each | instance. This means that two ECDSA digital signatures using exactly | |||

digital signature instance. This means that two ECDSA digital | the same input parameters will output different signature values | |||

signatures using exactly the same input parameters will output | because their K values will be different. A consequence of this is | |||

different signature values because their K values will be different. | that one cannot validate an ECDSA signature by recomputing the | |||

The consequence of this is that one must validate an ECDSA digital | signature and comparing the results. | |||

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

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 larger result values. | SHA-256 - just using the corresponding hash algorithm with | |||

correspondingly larger result values. For ECDSA P-384 SHA-384, R and | ||||

S will be 48 bytes each, resulting in a 96 byte array. For ECDSA | ||||

P-521 SHA-512, R and S will be 66 bytes each (so they can represent a | ||||

521-bit integer), resulting in a 132 byte array. | ||||

3.5. Creating a Plaintext JWS | 3.5. Using the Algorithm "none" | |||

To support use cases where the content is secured by a means other | JWSs MAY also be created that do not provide integrity protection. | |||

than a digital signature or MAC value, JWSs MAY also be created | Such a JWS is called a "Plaintext JWS". Plaintext JWSs MUST use the | |||

without them. These are called "Plaintext JWSs". Plaintext JWSs | "alg" value "none", and are formatted identically to other JWSs, but | |||

MUST use the "alg" value "none", and are formatted identically to | with an empty JWS Signature value. | |||

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

3.6. Additional Digital Signature/MAC Algorithms and Parameters | 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 registered | |||

the IANA JSON Web Signature and Encryption Algorithms registry | in the IANA JSON Web Signature and Encryption Algorithms registry | |||

Section 6.2 or be a URI that contains a collision resistant | Section 6.1 or be a URI that contains a Collision Resistant | |||

namespace. In particular, it is permissible to use the algorithm | Namespace. In particular, it is permissible to use the algorithm | |||

identifiers defined in XML DSIG [RFC3275], XML DSIG 2.0 | identifiers defined in XML DSIG [RFC3275], XML DSIG 2.0 | |||

[W3C.CR-xmldsig-core2-20120124], and related specifications as "alg" | [W3C.CR-xmldsig-core2-20120124], and related specifications as "alg" | |||

values. | values. | |||

As indicated by the common registry, JWSs and JWEs share a common | As indicated by the common registry, JWSs and JWEs share a common | |||

"alg" value space. The values used by the two specifications MUST be | "alg" value space. The values used by the two specifications MUST be | |||

distinct, as the "alg" value MAY be used to determine whether the | distinct, as the "alg" value MAY be used to determine whether the | |||

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

Likewise, additional reserved header parameter names MAY be defined | Likewise, additional reserved header parameter names MAY be defined | |||

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

registry Section 6.1. As indicated by the common registry, JWSs and | registry [JWS]. As indicated by the common registry, JWSs and JWEs | |||

JWEs share a common header parameter space; when a parameter is used | share a common header parameter space; when a parameter is used by | |||

by both specifications, its usage must be compatible between the | both specifications, its usage must be compatible between the | |||

specifications. | specifications. | |||

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

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

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

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

4.1. "alg" (Algorithm) Header Parameter Values for JWE | 4.1. "alg" (Algorithm) Header Parameter Values for JWE | |||

The table below is the set of "alg" (algorithm) header parameter | The table below is the set of "alg" (algorithm) header parameter | |||

values that are defined by this specification for use with JWE. | values that are defined by this specification for use with JWE. | |||

These algorithms are used to encrypt the CMK, producing the JWE | These algorithms are used to encrypt the CMK, producing the JWE | |||

Encrypted Key, or to use key agreement to agree upon the CMK. | Encrypted Key, or to use key agreement to agree upon the CMK. | |||

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

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

| Parameter | | | | Parameter | Algorithm | Requirements | | |||

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

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

| RSA1_5 | RSA using RSA-PKCS1-1.5 padding, as defined in RFC | | | RSA1_5 | RSAES-PKCS1-V1_5 [RFC3447] | REQUIRED | | |||

| | 3447 [RFC3447] | | | RSA-OAEP | RSAES using Optimal Asymmetric | OPTIONAL | | |||

| RSA-OAEP | RSA using Optimal Asymmetric Encryption Padding | | | | Encryption Padding (OAEP) [RFC3447], | | | |||

| | (OAEP), as defined in RFC 3447 [RFC3447] | | | | with the default parameters | | | |||

| ECDH-ES | Elliptic Curve Diffie-Hellman Ephemeral Static, as | | | | specified by RFC 3447 in Section | | | |||

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

| | KDF, as defined in Section 5.8.1 of [NIST.800-56A], | | | ECDH-ES | Elliptic Curve Diffie-Hellman | RECOMMENDED+ | | |||

| | where the Digest Method is SHA-256 and all OtherInfo | | | | Ephemeral Static [RFC6090], and | | | |||

| | parameters are the empty bit string | | | | using the Concat KDF, as defined in | | | |||

| A128KW | Advanced Encryption Standard (AES) Key Wrap Algorithm | | | | Section 5.8.1 of [NIST.800-56A], | | | |||

| | using 128 bit keys, as defined in RFC 3394 [RFC3394] | | | | where the Digest Method is SHA-256 | | | |||

| A256KW | Advanced Encryption Standard (AES) Key Wrap Algorithm | | | | and all OtherInfo parameters are the | | | |||

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

+-----------+-------------------------------------------------------+ | | A128KW | Advanced Encryption Standard (AES) | RECOMMENDED | | |||

| | Key Wrap Algorithm [RFC3394] using | | | ||||

| | 128 bit keys | | | ||||

| A256KW | AES Key Wrap Algorithm using 256 bit | RECOMMENDED | | ||||

| | keys | | | ||||

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

The use of "+" in the Implementation Requirements indicates that the | ||||

requirement strength is likely to be increased in a future version of | ||||

the specification. | ||||

4.2. "enc" (Encryption Method) Header Parameter Values for JWE | 4.2. "enc" (Encryption Method) Header Parameter Values for JWE | |||

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

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

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

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

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

| enc | Block Encryption Algorithm | | | enc | Block Encryption Algorithm | Implementation | | |||

| Parameter | | | | Parameter | | Requirements | | |||

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

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

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

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

| | padding, as defined in [FIPS.197] and [NIST.800-38A] | | | | with PKCS #5 padding [AES] | | | |||

| A256CBC | Advanced Encryption Standard (AES) using 256 bit keys | | | | [NIST.800-38A] using 128 bit keys | | | |||

| | in Cipher Block Chaining (CBC) mode using PKCS #5 | | | A256CBC | AES in CBC mode with PKCS #5 padding | REQUIRED | | |||

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

| A128GCM | Advanced Encryption Standard (AES) using 128 bit keys | | | A128GCM | AES in Galois/Counter Mode (GCM) | RECOMMENDED | | |||

| | in Galois/Counter Mode (GCM), as defined in | | | | [AES] [NIST.800-38D] using 128 bit | | | |||

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

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

| | in Galois/Counter Mode (GCM), as defined in | | +-----------+--------------------------------------+----------------+ | |||

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

+-----------+-------------------------------------------------------+ | All the names are short because a core goal of JWE is for the | |||

representations to be compact. However, there is no a priori length | ||||

restriction on "alg" 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 "alg" and "enc" algorithms, only RSA-PKCS1-1.5 with 2048 bit | ||||

keys, AES-128-KW, AES-256-KW, AES-128-CBC, and AES-256-CBC MUST be | ||||

implemented by conforming JWE implementations. It is RECOMMENDED | ||||

that implementations also support ECDH-ES with 256 bit keys, AES-128- | ||||

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

OPTIONAL. | ||||

4.3. "int" (Integrity Algorithm) Header Parameter Values for JWE | 4.3. "int" (Integrity Algorithm) Header Parameter Values for JWE | |||

The table below is the set of "int" (integrity algorithm) header | The table below is the set of "int" (integrity algorithm) header | |||

parameter values defined by this specification for use with JWE. | parameter values defined by this specification for use with JWE. | |||

Note that these are the HMAC SHA subset of the "alg" (algorithm) | Note that these are the HMAC SHA subset of the "alg" (algorithm) | |||

header parameter values defined for use with JWS Section 3.1. /> | header parameter values defined for use with JWS Section 3.1. | |||

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

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

+---------------------+-----------------------------------+ | | Value | | Requirements | | |||

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

| HS384 | HMAC using SHA-384 hash algorithm | | | HS256 | HMAC using SHA-256 hash | REQUIRED | | |||

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

+---------------------+-----------------------------------+ | | HS384 | HMAC using SHA-384 hash | OPTIONAL | | |||

| | algorithm | | | ||||

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

| | algorithm | | | ||||

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

Of these "int" algorithms, only HMAC SHA-256 MUST be implemented by | 4.4. "kdf" (Key Derivation Function) Header Parameter Values for JWE | |||

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 | The table below is the set of "kdf" (key derivation function) header | |||

parameter values defined by this specification for use with JWE. | ||||

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 | | kdf | Algorithm | Implementation | | |||

"alg" header parameter value "RSA1_5" is used in this case. | | Parameter | | Requirements | | |||

| Value | | | | ||||

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

| CS256 | Concat KDF, as defined in Section | REQUIRED | | ||||

| | 5.8.1 of [NIST.800-56A], with | | | ||||

| | parameters per Section 4.12, using | | | ||||

| | SHA-256 as the digest method | | | ||||

| CS384 | Concat KDF with parameters per | OPTIONAL | | ||||

| | Section 4.12, using SHA-384 as the | | | ||||

| | digest method | | | ||||

| CS512 | Concat KDF with parameters per | OPTIONAL | | ||||

| | Section 4.12, using SHA-512 as the | | | ||||

| | digest method | | | ||||

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

4.5. Key Encryption with RSAES-PKCS1-V1_5 | ||||

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

RSAES-PKCS1-V1_5 [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. | A key of size 2048 bits or larger MUST be used with this algorithm. | |||

4.5. Key Encryption with RSA using Optimal Asymmetric Encryption | 4.6. Key Encryption with RSAES OAEP | |||

Padding (OAEP) | ||||

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

using Optimal Asymmetric Encryption Padding (OAEP), as defined in RFC | using Optimal Asymmetric Encryption Padding (OAEP) [RFC3447], with | |||

3447 [RFC3447]. The "alg" header parameter value "RSA-OAEP" is used | the default parameters specified by RFC 3447 in Section A.2.1. The | |||

in this case. | "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. | 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 | 4.7. Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static | |||

(ECDH-ES) | (ECDH-ES) | |||

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

Elliptic Curve Diffie-Hellman Ephemeral Static, as defined in RFC | Elliptic Curve Diffie-Hellman Ephemeral Static [RFC6090], and using | |||

6090 [RFC6090], and using the Concat KDF, as defined in Section 5.8.1 | the Concat KDF, as defined in Section 5.8.1 of [NIST.800-56A], where | |||

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

OtherInfo parameters are the empty bit string. The "alg" header | empty bit string. The "alg" header parameter value "ECDH-ES" is used | |||

parameter value "ECDH-ES" is used in this case. | in this case. | |||

A key of size 160 bits or larger MUST be used for the Elliptic Curve | The output of the Concat KDF MUST be a key of the same length as that | |||

keys used with this algorithm. The output of the Concat KDF MUST be | used by the "enc" algorithm. | |||

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 | A new "epk" (ephemeral public key) value MUST be generated for each | |||

key agreement transaction. | key agreement transaction. | |||

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

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

Advanced Encryption Standard (AES) Key Wrap Algorithm using 128 or | Advanced Encryption Standard (AES) Key Wrap Algorithm [RFC3394] using | |||

256 bit keys, as defined in RFC 3394 [RFC3394]. The "alg" header | 128 or 256 bit keys. The "alg" header parameter values "A128KW" or | |||

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

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

This section defines the specifics of encrypting the JWE Plaintext | This section defines the specifics of encrypting the JWE Plaintext | |||

with Advanced Encryption Standard (AES) in Cipher Block Chaining | with Advanced Encryption Standard (AES) in Cipher Block Chaining | |||

(CBC) mode using PKCS #5 padding using 128 or 256 bit keys, as | (CBC) mode with PKCS #5 padding [AES] [NIST.800-38A] using 128 or 256 | |||

defined in [FIPS.197] and [NIST.800-38A]. The "enc" header parameter | bit keys. The "enc" header parameter values "A128CBC" or "A256CBC" | |||

values "A128CBC" or "A256CBC" are used in this case. | are used in this case. | |||

Use of an Initialization Vector (IV) of size 128 bits is RECOMMENDED | Use of an initialization vector of size 128 bits is REQUIRED with | |||

with this algorithm. | this algorithm. | |||

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

This section defines the specifics of encrypting the JWE Plaintext | This section defines the specifics of encrypting the JWE Plaintext | |||

with Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) | with Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) | |||

using 128 or 256 bit keys, as defined in [FIPS.197] and | [AES] [NIST.800-38D] using 128 or 256 bit keys. The "enc" header | |||

[NIST.800-38D]. The "enc" header parameter values "A128GCM" or | parameter values "A128GCM" or "A256GCM" are used in this case. | |||

"A256GCM" are used in this case. | ||||

Use of an Initialization Vector (IV) of size 96 bits is REQUIRED with | Use of an initialization vector of size 96 bits is REQUIRED with this | |||

this algorithm. | algorithm. | |||

The "additional authenticated data" parameter value for the | The "additional authenticated data" parameter is used to secure the | |||

encryption is the concatenation of the Encoded JWE Header, a period | header and key values, as specified for AEAD algorithms in Section 5 | |||

('.') character, and the Encoded JWE Encrypted Key. | of [JWE]. | |||

The requested size of the "authentication tag" output MUST be the | The requested size of the "authentication tag" output MUST be 128 | |||

same as the key size (for instance, 128 bits for "A128GCM"). | bits, regardless of the key size. | |||

As GCM is an AEAD algorithm, the JWE Integrity Value is set to be the | As GCM is an AEAD algorithm, the JWE Integrity Value is set to be the | |||

"authentication tag" value produced by the encryption. | "authentication tag" value produced by the encryption. | |||

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

SHA-512 | SHA-512 | |||

This section defines the specifics of computing a JWE Integrity Value | 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 | with HMAC SHA-256, HMAC SHA-384, or HMAC SHA-512 [SHS]. Other than | |||

180-3 [FIPS.180-3]. The "int" header parameter values "HS256", | as stated below, these computations are performed identically to | |||

"HS384", or "HS512" are used in this case. | those specified in Section 3.2. | |||

A key of the same size as the hash output (for instance, 256 bits for | A key of the same size as the hash output (for instance, 256 bits for | |||

"HS256") or larger MUST be used with this algorithm. | "HS256") MUST be used with this algorithm. | |||

4.11. Additional Encryption Algorithms and Parameters | Per Section 9 of [JWE], the JWS Secured Input value used contains the | |||

header, encrypted key, and ciphertext. | ||||

4.12. Key Derivation with Concat KDF and SHA-256, SHA-384, or SHA-512 | ||||

The key derivation process derives CEK and CIK values from the CMK. | ||||

It uses as a primitive a Key Derivation Function (KDF) which | ||||

notionally takes three arguments: | ||||

MasterKey: The master key used to compute the individual use keys | ||||

Label: The use key label, used to differentiate individual use keys | ||||

Length: The desired length of the use key | ||||

This section defines the specifics of using the Concat KDF, as | ||||

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

is one of SHA-256, SHA-384, or SHA-512, the SuppPubInfo parameter is | ||||

the Label, and the remaining OtherInfo parameters are the empty bit | ||||

string. | ||||

The "kdf" (key derivation function) header parameter values "CS256", | ||||

"CS384", and "CS512" are respectively used in the JWE Header to | ||||

indicate the use of the Concat KDF as above with the respective | ||||

digest methods. If the "kdf" header parameter is omitted when an | ||||

AEAD "enc" algorithm is not used, this is equivalent to specifying | ||||

use of the "CS256" key derivation function. | ||||

To compute the CEK from the CMK, the ASCII label "Encryption" ([69, | ||||

110, 99, 114, 121, 112, 116, 105, 111, 110]) is used. Use the key | ||||

size for the "enc" algorithm as the CEK desired key length. | ||||

To compute the CIK from the CMK, the ASCII label "Integrity" ([73, | ||||

110, 116, 101, 103, 114, 105, 116, 121]) is used. Use the minimum | ||||

key size for the "int" algorithm (for instance, 256 bits for "HS256") | ||||

as the CIK desired key length. | ||||

4.13. 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), "enc" (encryption method), and "int" (integrity | "alg" (algorithm), "enc" (encryption method), and "int" (integrity | |||

algorithm) header parameter values being defined to refer to them. | algorithm) header parameter values being defined to refer to them. | |||

New "alg", "enc", and "int" header parameter values SHOULD either be | New "alg", "enc", and "int" header parameter values SHOULD either be | |||

defined in the IANA JSON Web Signature and Encryption Algorithms | registered in the IANA JSON Web Signature and Encryption Algorithms | |||

registry Section 6.2 or be a URI that contains a collision resistant | registry Section 6.1 or be a URI that contains a Collision Resistant | |||

namespace. In particular, it is permissible to use the algorithm | Namespace. In particular, it is permissible to use the algorithm | |||

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

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

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

As indicated by the common registry, JWSs and JWEs share a common | As indicated by the common registry, JWSs and JWEs share a common | |||

"alg" value space. The values used by the two specifications MUST be | "alg" value space. The values used by the two specifications MUST be | |||

distinct, as the "alg" value MAY be used to determine whether the | distinct, as the "alg" value MAY be used to determine whether the | |||

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

Likewise, additional reserved header parameter names MAY be defined | Likewise, additional reserved header parameter names MAY be defined | |||

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

registry Section 6.1. As indicated by the common registry, JWSs and | registry [JWS]. As indicated by the common registry, JWSs and JWEs | |||

JWEs share a common header parameter space; when a parameter is used | share a common header parameter space; when a parameter is used by | |||

by both specifications, its usage must be compatible between the | both specifications, its usage must be compatible between the | |||

specifications. | specifications. | |||

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

A JSON Web Key (JWK) [JWK] is a JSON data structure that represents a | A JSON Web Key (JWK) [JWK] is a JavaScript Object Notation (JSON) | |||

public key. A JSON Web Key Set (JWK Set) is a JSON data structure | [RFC4627] data structure that represents a public key. A JSON Web | |||

for representing a set of JWKs. This section specifies a set of | Key Set (JWK Set) is a JSON data structure for representing a set of | |||

algorithm families to be used for those public keys and the algorithm | JWKs. This section specifies a set of algorithm families to be used | |||

family specific parameters for representing those keys. | for those public keys and the algorithm family specific parameters | |||

for representing those keys. | ||||

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

The table below is the set of "alg" (algorithm family) parameter | The table below is the set of "alg" (algorithm family) parameter | |||

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

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

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

+---------------------+----------------------------------------+ | | Value | | Requirements | | |||

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

| RSA | RSA [RFC3447] key family | | | EC | Elliptic Curve [DSS] | RECOMMENDED+ | | |||

+---------------------+----------------------------------------+ | | | key family | | | |||

| RSA | RSA [RFC3447] key | REQUIRED | | ||||

| | family | | | ||||

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

All the names are short because a core goal of JWK is for the | ||||

representations to be compact. However, there is no a priori length | ||||

restriction on "alg" values. | ||||

The use of "+" in the Implementation Requirements indicates that the | ||||

requirement strength is likely to be increased in a future version of | ||||

the specification. | ||||

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

JWKs can represent Elliptic Curve [FIPS.186-3] keys. In this case, | JWKs can represent Elliptic Curve [DSS] keys. In this case, the | |||

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

members MUST be present: | members MUST be present: | |||

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

The "crv" (curve) member identifies the cryptographic curve used with | The "crv" (curve) member identifies the cryptographic curve used with | |||

the key. Values defined by this specification are "P-256", "P-384" | the key. Curve values from [DSS] used by this specification are: | |||

and "P-521". Additional "crv" values MAY be used, provided they are | ||||

understood by implementations using that Elliptic Curve key. The | o "P-256" | |||

"crv" value is case sensitive. Its value MUST be a string. | ||||

o "P-384" | ||||

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

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

The "x" (x coordinate) member contains the x coordinate for the | The "x" (x coordinate) member contains the x coordinate for the | |||

elliptic curve point. It is represented as the base64url encoding of | elliptic curve point. It is represented as the base64url encoding of | |||

the coordinate's big endian representation. | the coordinate's big endian representation. | |||

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

The "y" (y coordinate) member contains the y coordinate for the | The "y" (y coordinate) member contains the y coordinate for the | |||

skipping to change at page 15, line 9 | skipping to change at page 19, line 37 | |||

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

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

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

MUST be present: | MUST be present: | |||

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

The "mod" (modulus) member contains the modulus value for the RSA | The "mod" (modulus) member contains the modulus value for the RSA | |||

public key. It is represented as the base64url encoding of the | public key. It is represented as the base64url encoding of the | |||

value's big endian representation. | value's unsigned big endian representation. | |||

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

The "exp" (exponent) member contains the exponent value for the RSA | The "exp" (exponent) member contains the exponent value for the RSA | |||

public key. It is represented as the base64url encoding of the | public key. It is represented as the base64url encoding of the | |||

value's big endian representation. | value's unsigned big endian representation. | |||

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

Public keys using additional algorithm families MAY be represented | Public keys using additional algorithm families MAY be represented | |||

using JWK data structures with corresponding "alg" (algorithm family) | using JWK data structures with corresponding "alg" (algorithm family) | |||

parameter values being defined to refer to them. New "alg" parameter | parameter values being defined to refer to them. New "alg" parameter | |||

values SHOULD either be defined in the IANA JSON Web Key Algorithm | values SHOULD either be registered in the IANA JSON Web Key Algorithm | |||

Families registry Section 6.5 or be a URI that contains a collision | Families registry Section 6.2 or be a URI that contains a Collision | |||

resistant namespace. | Resistant Namespace. | |||

Likewise, parameters for representing keys for additional algorithm | Likewise, parameters for representing keys for additional algorithm | |||

families or additional key properties SHOULD either be defined in the | families or additional key properties SHOULD either be registered in | |||

IANA JSON Web Key Parameters registry Section 6.4 or be a URI that | the IANA JSON Web Key Parameters registry [JWK] or be a URI that | |||

contains a collision resistant namespace. | contains a Collision Resistant Namespace. | |||

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

6.1. JSON Web Signature and Encryption Header Parameters Registry | The following registration procedure is used for all the registries | |||

established by this specification. | ||||

This specification establishes the IANA JSON Web Signature and | Values are registered with a Specification Required [RFC5226] after a | |||

Encryption Header Parameters registry for reserved JWS and JWE header | two week review period on the [TBD]@ietf.org mailing list, on the | |||

parameter names. Inclusion in the registry is RFC Required in the | advice of one or more Designated Experts. However, to allow for the | |||

RFC 5226 [RFC5226] sense. The registry records the reserved header | allocation of values prior to publication, the Designated Expert(s) | |||

parameter name and a reference to the RFC that defines it. This | may approve registration once they are satisfied that such a | |||

specification registers the header parameter names defined in JSON | specification will be published. | |||

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 | Registration requests must be sent to the [TBD]@ietf.org mailing list | |||

for review and comment, with an appropriate subject (e.g., "Request | ||||

for access token type: example"). [[ Note to RFC-EDITOR: The name of | ||||

the mailing list should be determined in consultation with the IESG | ||||

and IANA. Suggested name: jose-reg-review. ]] | ||||

Within the review period, the Designated Expert(s) will either | ||||

approve or deny the registration request, communicating this decision | ||||

to the review list and IANA. Denials should include an explanation | ||||

and, if applicable, suggestions as to how to make the request | ||||

successful. | ||||

IANA must only accept registry updates from the Designated Expert(s), | ||||

and should direct all requests for registration to the review mailing | ||||

list. | ||||

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

This specification establishes the IANA JSON Web Signature and | This specification establishes the IANA JSON Web Signature and | |||

Encryption Algorithms registry for values of the JWS and JWE "alg" | Encryption Algorithms registry for values of the JWS and JWE "alg" | |||

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

algorithm) header parameters. Inclusion in the registry is RFC | algorithm) header parameters. The registry records the algorithm | |||

Required in the RFC 5226 [RFC5226] sense. The registry records the | name, the algorithm usage locations from the set "alg", "enc", and | |||

algorithm usage "alg", "enc", or "int", the value, and a pointer to | "int", implementation requirements, and a reference to the | |||

the RFC that defines it. This specification registers the values | specification that defines it. The same algorithm name may be | |||

defined in Section 3.1, Section 4.1, Section 4.2, and Section 4.3. | registered multiple times, provided that the sets of usage locations | |||

are disjoint. The implementation requirements of an algorithm may be | ||||

changed over time by the Designated Experts(s) as the cryptographic | ||||

landscape evolves, for instance, to change the status of an algorithm | ||||

to DEPRECATED, or to change the status of an algorithm from OPTIONAL | ||||

to RECOMMENDED or REQUIRED. | ||||

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

This specification establishes the IANA JSON Web Signature and | Algorithm Name: | |||

Encryption "typ" Values registry for values of the JWS and JWE "typ" | The name requested (e.g., "example"). | |||

(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 | Algorithm Usage Location(s): | |||

registered as new "typ" values; rather, new "typ" values MAY be | The algorithm usage, which must be one or more of the values | |||

registered as short names for MIME types. | "alg", "enc", "int", or "kdf". | |||

6.4. JSON Web Key Parameters Registry | Implementation Requirements: | |||

The algorithm implementation requirements, which must be one the | ||||

words REQUIRED, RECOMMENDED, OPTIONAL, or DEPRECATED. Optionally, | ||||

the word may be followed by a "+" or "-". The use of "+" | ||||

indicates that the requirement strength is likely to be increased | ||||

in a future version of the specification. The use of "-" | ||||

indicates that the requirement strength is likely to be decreased | ||||

in a future version of the specification. | ||||

This specification establishes the IANA JSON Web Key Parameters | Change Controller: | |||

registry for reserved JWK parameter names. Inclusion in the registry | For standards-track RFCs, state "IETF". For others, give the name | |||

is RFC Required in the RFC 5226 [RFC5226] sense. The registry | of the responsible party. Other details (e.g., postal address, | |||

records the reserved parameter name and a reference to the RFC that | e-mail address, home page URI) may also be included. | |||

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 | Specification Document(s): | |||

Reference to the document that specifies the parameter, preferably | ||||

including a URI that can be used to retrieve a copy of the | ||||

document. An indication of the relevant sections may also be | ||||

included, but is not required. | ||||

6.1.2. Initial Registry Contents | ||||

o Algorithm Name: "HS256" | ||||

o Algorithm Usage Location(s): "alg", "int" | ||||

o Implementation Requirements: REQUIRED | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 3.1 and Section 4.3 of [[ this | ||||

document ]] | ||||

o Algorithm Name: "HS384" | ||||

o Algorithm Usage Location(s): "alg", "int" | ||||

o Implementation Requirements: OPTIONAL | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 3.1 and Section 4.3 of [[ this | ||||

document ]] | ||||

o Algorithm Name: "HS512" | ||||

o Algorithm Usage Location(s): "alg", "int" | ||||

o Implementation Requirements: OPTIONAL | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 3.1 and Section 4.3 of [[ this | ||||

document ]] | ||||

o Algorithm Name: "RS256" | ||||

o Algorithm Usage Location(s): "alg" | ||||

o Implementation Requirements: RECOMMENDED | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 3.1 of [[ this document ]] | ||||

o Algorithm Name: "RS384" | ||||

o Algorithm Usage Location(s): "alg" | ||||

o Implementation Requirements: OPTIONAL | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 3.1 of [[ this document ]] | ||||

o Algorithm Name: "RS512" | ||||

o Algorithm Usage Location(s): "alg" | ||||

o Implementation Requirements: OPTIONAL | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 3.1 of [[ this document ]] | ||||

o Algorithm Name: "ES256" | ||||

o Algorithm Usage Location(s): "alg" | ||||

o Implementation Requirements: RECOMMENDED+ | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 3.1 of [[ this document ]] | ||||

o Algorithm Name: "ES384" | ||||

o Algorithm Usage Location(s): "alg" | ||||

o Implementation Requirements: OPTIONAL | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 3.1 of [[ this document ]] | ||||

o Algorithm Name: "ES512" | ||||

o Algorithm Usage Location(s): "alg" | ||||

o Implementation Requirements: OPTIONAL | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 3.1 of [[ this document ]] | ||||

o Algorithm Name: "none" | ||||

o Algorithm Usage Location(s): "alg" | ||||

o Implementation Requirements: REQUIRED | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 3.1 of [[ this document ]] | ||||

o Algorithm Name: "RSA1_5" | ||||

o Algorithm Usage Location(s): "alg" | ||||

o Implementation Requirements: REQUIRED | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 4.1 of [[ this document ]] | ||||

o Algorithm Name: "RSA-OAEP" | ||||

o Algorithm Usage Location(s): "alg" | ||||

o Implementation Requirements: OPTIONAL | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 4.1 of [[ this document ]] | ||||

o Algorithm Name: "ECDH-ES" | ||||

o Algorithm Usage Location(s): "alg" | ||||

o Implementation Requirements: RECOMMENDED+ | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 4.1 of [[ this document ]] | ||||

o Algorithm Name: "A128KW" | ||||

o Algorithm Usage Location(s): "alg" | ||||

o Implementation Requirements: RECOMMENDED | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 4.1 of [[ this document ]] | ||||

o Algorithm Name: "A256KW" | ||||

o Algorithm Usage Location(s): "alg" | ||||

o Implementation Requirements: RECOMMENDED | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 4.1 of [[ this document ]] | ||||

o Algorithm Name: "A128CBC" | ||||

o Algorithm Usage Location(s): "enc" | ||||

o Implementation Requirements: REQUIRED | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 4.2 of [[ this document ]] | ||||

o Algorithm Name: "A256CBC" | ||||

o Algorithm Usage Location(s): "enc" | ||||

o Implementation Requirements: REQUIRED | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 4.2 of [[ this document ]] | ||||

o Algorithm Name: "A128GCM" | ||||

o Algorithm Usage Location(s): "enc" | ||||

o Implementation Requirements: RECOMMENDED | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 4.2 of [[ this document ]] | ||||

o Algorithm Name: "A256GCM" | ||||

o Algorithm Usage Location(s): "enc" | ||||

o Implementation Requirements: RECOMMENDED | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 4.2 of [[ this document ]] | ||||

o Algorithm Name: "CS256" | ||||

o Algorithm Usage Location(s): "kdf" | ||||

o Implementation Requirements: REQUIRED | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 4.4 of [[ this document ]] | ||||

o Algorithm Name: "CS384" | ||||

o Algorithm Usage Location(s): "kdf" | ||||

o Implementation Requirements: OPTIONAL | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 4.4 of [[ this document ]] | ||||

o Algorithm Name: "CS512" | ||||

o Algorithm Usage Location(s): "kdf" | ||||

o Implementation Requirements: OPTIONAL | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 4.4 of [[ this document ]] | ||||

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

This specification establishes the IANA JSON Web Key Algorithm | This specification establishes the IANA JSON Web Key Algorithm | |||

Families registry for values of the JWK "alg" (algorithm family) | Families registry for values of the JWK "alg" (algorithm family) | |||

parameter. Inclusion in the registry is RFC Required in the RFC 5226 | parameter. The registry records the "alg" value and a reference to | |||

[RFC5226] sense. The registry records the "alg" value and a pointer | the specification that defines it. This specification registers the | |||

to the RFC that defines it. This specification registers the values | values defined in Section 5.1. | |||

defined in Section 5.1. | ||||

6.2.1. Registration Template | ||||

"alg" Parameter Value: | ||||

The name requested (e.g., "example"). | ||||

Change Controller: | ||||

For standards-track RFCs, state "IETF". For others, give the name | ||||

of the responsible party. Other details (e.g., postal address, | ||||

e-mail address, home page URI) may also be included. | ||||

Implementation Requirements: | ||||

The algorithm implementation requirements, which must be one the | ||||

words REQUIRED, RECOMMENDED, OPTIONAL, or DEPRECATED. Optionally, | ||||

the word may be followed by a "+" or "-". The use of "+" | ||||

indicates that the requirement strength is likely to be increased | ||||

in a future version of the specification. The use of "-" | ||||

indicates that the requirement strength is likely to be decreased | ||||

in a future version of the specification. | ||||

Specification Document(s): | ||||

Reference to the document that specifies the parameter, preferably | ||||

including a URI that can be used to retrieve a copy of the | ||||

document. An indication of the relevant sections may also be | ||||

included, but is not required. | ||||

6.2.2. Initial Registry Contents | ||||

o "alg" Parameter Value: "EC" | ||||

o Implementation Requirements: RECOMMENDED+ | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 5.1 of [[ this document ]] | ||||

o "alg" Parameter Value: "RSA" | ||||

o Implementation Requirements: REQUIRED | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 5.1 of [[ this document ]] | ||||

6.3. JSON Web Key Parameters Registration | ||||

This specification registers the parameter names defined in | ||||

Section 5.2 and Section 5.3 in the IANA JSON Web Key Parameters | ||||

registry [JWK]. | ||||

6.3.1. Registry Contents | ||||

o Parameter Name: "crv" | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 5.2.1 of [[ this document ]] | ||||

o Parameter Name: "x" | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 5.2.2 of [[ this document ]] | ||||

o Parameter Name: "y" | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 5.2.3 of [[ this document ]] | ||||

o Parameter Name: "mod" | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 5.3.1 of [[ this document ]] | ||||

o Parameter Name: "exp" | ||||

o Change Controller: IETF | ||||

o Specification Document(s): Section 5.3.2 of [[ this document ]] | ||||

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

The security considerations in the JWS, JWE, and JWK specifications | All of the security issues faced by any cryptographic application | |||

also apply to this specification. | must be faced by a JWS/JWE/JWK agent. Among these issues are | |||

protecting the user's private key, preventing various attacks, and | ||||

helping the user avoid mistakes such as inadvertently encrypting a | ||||

message for the wrong recipient. The entire list of security | ||||

considerations is beyond the scope of this document, but some | ||||

significant concerns are listed here. | ||||

The security considerations in [AES], [DSS], [JWE], [JWK], [JWS], | ||||

[NIST.800-38A], [NIST.800-38D], [NIST.800-56A], [RFC2104], [RFC3394], | ||||

[RFC3447], [RFC5116], [RFC6090], and [SHS] apply to this | ||||

specification. | ||||

Eventually the algorithms and/or key sizes currently described in | Eventually the algorithms and/or key sizes currently described in | |||

this specification will no longer be considered sufficiently secure | this specification will no longer be considered sufficiently secure | |||

and will be removed. Therefore, implementers and deployments must be | and will be removed. Therefore, implementers and deployments must be | |||

prepared for this eventuality. | prepared for this eventuality. | |||

8. Open Issues and Things To Be Done (TBD) | Algorithms of matching strength should be used together whenever | |||

possible. For instance, when AES Key Wrap is used with a given key | ||||

size, using the same key size for AES CBC or GCM is recommended. | ||||

Likewise, when AES CBC is used with a 128 bit key, using HMAC SHA-256 | ||||

as the integrity algorithm is recommended, whereas when AES CBC is | ||||

used with a 256 bit key, using HMAC SHA-512 as the integrity | ||||

algorithm is recommended. | ||||

The following items remain to be done in this draft: | 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, this specification does include | ||||

RSASSA-PKCS1, for interoperability reasons, because it commonly | ||||

implemented. | ||||

o Find values for encryption algorithm cross-reference table | Keys used with RSAES-PKCS1-v1_5 must follow the constraints in | |||

currently listed as "TBD" or determine that they do not exist. | Section 7.2 of RFC 3447 [RFC3447]. In particular, keys with a low | |||

public key exponent value must not be used. | ||||

9. References | Plaintext JWSs (JWSs that use the "alg" value "none") provide no | |||

integrity protection. Thus, they must only be used in contexts where | ||||

the payload is secured by means other than a digital signature or MAC | ||||

value, or need not be secured. | ||||

9.1. Normative References | Receiving agents that validate signatures and sending agents that | |||

encrypt messages need to be cautious of cryptographic processing | ||||

usage when validating signatures and encrypting messages using keys | ||||

larger than those mandated in this specification. An attacker could | ||||

send certificates with keys that would result in excessive | ||||

cryptographic processing, for example, keys larger than those | ||||

mandated in this specification, which could swamp the processing | ||||

element. Agents that use such keys without first validating the | ||||

certificate to a trust anchor are advised to have some sort of | ||||

cryptographic resource management system to prevent such attacks. | ||||

[FIPS.180-3] | 8. Open Issues | |||

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

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

[FIPS.186-3] | [[ to be removed by the RFC editor before publication as an RFC ]] | |||

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

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

[FIPS.197] | The following items remain to be considered or done in this draft: | |||

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

o Should we use the "alg" value as the AlgorithmID input to the | ||||

Concat KDF when doing key agreement? Or is an AlgorithmID value | ||||

unnecessary in the way that we are using Concat? | ||||

o Should we use the "enc" and "int" values as AlgorithmID inputs to | ||||

the Concat KDF when doing key derivation? Or is an AlgorithmID | ||||

value unnecessary in the way that we are using Concat? | ||||

o Do we want to add AES ECB as a (non-authenticated) key wrap | ||||

algorithm? | ||||

9. References | ||||

9.1. Normative References | ||||

[AES] National Institute of Standards and Technology (NIST), | ||||

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

November 2001. | November 2001. | |||

[DSS] National Institute of Standards and Technology, "Digital | ||||

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

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

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

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

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

Signature (JWS)", May 2012. | Signature (JWS)", July 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. | |||

[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography | [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography | |||

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

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO | ||||

10646", STD 63, RFC 3629, November 2003. | ||||

[RFC4627] Crockford, D., "The application/json Media Type for | ||||

JavaScript Object Notation (JSON)", RFC 4627, July 2006. | ||||

[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data | ||||

Encodings", RFC 4648, October 2006. | ||||

[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated | ||||

Encryption", RFC 5116, January 2008. | ||||

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

[SHS] National Institute of Standards and Technology, "Secure | ||||

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

[USASCII] American National Standards Institute, "Coded Character | ||||

Set -- 7-bit American Standard Code for Information | ||||

Interchange", ANSI X3.4, 1986. | ||||

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

skipping to change at page 19, line 9 | skipping to change at page 31, line 45 | |||

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

[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally | ||||

Unique IDentifier (UUID) URN Namespace", RFC 4122, | ||||

July 2005. | ||||

[W3C.CR-xmldsig-core2-20120124] | [W3C.CR-xmldsig-core2-20120124] | |||

Eastlake, D., Reagle, J., Yiu, K., Solo, D., Datta, P., | Reagle, J., Solo, D., Datta, P., Hirsch, F., Eastlake, D., | |||

Hirsch, F., Cantor, S., and T. Roessler, "XML Signature | Roessler, T., Cantor, S., and K. Yiu, "XML Signature | |||

Syntax and Processing Version 2.0", World Wide Web | Syntax and Processing Version 2.0", World Wide Web | |||

Consortium CR CR-xmldsig-core2-20120124, January 2012, | Consortium CR CR-xmldsig-core2-20120124, January 2012, | |||

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

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

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

"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-20120313, | Wide Web Consortium CR CR-xmlenc-core1-20120313, | |||

March 2012, | March 2012, | |||

<http://www.w3.org/TR/2012/CR-xmlenc-core1-20120313>. | <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>. | |||

skipping to change at page 20, line 18 | skipping to change at page 33, line 11 | |||

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

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

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

| HMAC | HS5 | http://www.w3.org/2001/04/ | HmacSHA5 | 1.2.840.113 | | | HMAC | HS5 | http://www.w3.org/2001/04/ | HmacSHA5 | 1.2.840.113 | | |||

| using | 12 | xmldsig-more#hmac-sha512 | 12 | 549.2.11 | | | using | 12 | xmldsig-more#hmac-sha512 | 12 | 549.2.11 | | |||

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

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

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

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

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

| RSA | RS2 | http://www.w3.org/2001/04/ | SHA256wi | 1.2.840.113 | | | RSASS | RS2 | http://www.w3.org/2001/04/ | SHA256wi | 1.2.840.113 | | |||

| using | 56 | xmldsig-more#rsa-sha256 | thRSA | 549.1.1.11 | | | A | 56 | xmldsig-more#rsa-sha256 | thRSA | 549.1.1.11 | | |||

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

| 56 | | | | | | | gSHA- | | | | | | |||

| hash | | | | | | | 256 | | | | | | |||

| algo | | | | | | | has | | | | | | |||

| rithm | | | | | | | h alg | | | | | | |||

| RSA | RS3 | http://www.w3.org/2001/04/ | SHA384wi | 1.2.840.113 | | | orith | | | | | | |||

| using | 84 | xmldsig-more#rsa-sha384 | thRSA | 549.1.1.12 | | | m | | | | | | |||

| SHA-3 | | | | | | | RSASS | RS3 | http://www.w3.org/2001/04/ | SHA384wi | 1.2.840.113 | | |||

| 84 | | | | | | | A | 84 | xmldsig-more#rsa-sha384 | thRSA | 549.1.1.12 | | |||

| hash | | | | | | | usin | | | | | | |||

| algo | | | | | | | gSHA- | | | | | | |||

| rithm | | | | | | | 384 | | | | | | |||

| RSA | RS5 | http://www.w3.org/2001/04/ | SHA512wi | 1.2.840.113 | | | has | | | | | | |||

| using | 12 | xmldsig-more#rsa-sha512 | thRSA | 549.1.1.13 | | | h alg | | | | | | |||

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

| 12 | | | | | | | m | | | | | | |||

| hash | | | | | | | RSASS | RS5 | http://www.w3.org/2001/04/ | SHA512wi | 1.2.840.113 | | |||

| algo | | | | | | | A | 12 | xmldsig-more#rsa-sha512 | thRSA | 549.1.1.13 | | |||

| rithm | | | | | | | usin | | | | | | |||

| gSHA- | | | | | | ||||

| 512 | | | | | | ||||

| has | | | | | | ||||

| h alg | | | | | | ||||

| orith | | | | | | ||||

| m | | | | | | ||||

| ECDSA | ES2 | http://www.w3.org/2001/04/ | SHA256wi | 1.2.840.100 | | | ECDSA | ES2 | http://www.w3.org/2001/04/ | SHA256wi | 1.2.840.100 | | |||

| using | 56 | xmldsig-more#ecdsa-sha256 | thECDSA | 45.4.3.2 | | | using | 56 | xmldsig-more#ecdsa-sha256 | thECDSA | 45.4.3.2 | | |||

| P-256 | | | | | | | P-256 | | | | | | |||

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

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

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

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

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

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

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

skipping to change at page 21, line 37 | skipping to change at page 34, line 37 | |||

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-20120313], 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 | | | Algorith | JWE | XML ENC | JCA | | |||

| hm | | | | | | m | | | | | |||

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

| RSA | RSA1_ | http://www.w3.org/2001/04 | RSA/ECB/PKCS1Paddin | | | RSAES-PK | RSA1 | http://www.w3.org/2001/04 | RSA/None/PKCS1Paddi | | |||

| using | 5 | /xmlenc#rsa-1_5 | g | | | CS1-V1_5 | _5 | /xmlenc#rsa-1_5 | ng | | |||

| RSA-PKC | | | | | | RSAES | RSA- | http://www.w3.org/2001/04 | RSA/None/OAEPWithSH | | |||

| S1-1.5 | | | | | | using | OAEP | /xmlenc#rsa-oaep-mgf1p | A-1AndMGF1Padding | | |||

| paddin | | | | | | Optimal | | | | | |||

| g | | | | | | Asymmetr | | | | | |||

| RSA | RSA-O | http://www.w3.org/2001/04 | RSA/ECB/OAEPWithSHA | | | ic | | | | | |||

| using | AEP | /xmlenc#rsa-oaep-mgf1p | -1AndMGF1Padding | | | Encrypt | | | | | |||

| Optimal | | | | | | ion | | | | | |||

| Asymmet | | | | | | Paddin | | | | | |||

| ric | | | | | | g (OAEP) | | | | | |||

| Encryp | | | | | | Elliptic | ECDH | http://www.w3.org/2009/xm | | | |||

| tion | | | | | | Curve | -ES | lenc11#ECDH-ES | | | |||

| Paddi | | | | | | Diffie-H | | | | | |||

| ng(OAEP | | | | | | ellman | | | | | |||

| ) | | | | | | Ephemer | | | | | |||

| Ellipti | ECDH- | http://www.w3.org/2009/xm | TBD | | | alStatic | | | | | |||

| cCurve | ES | lenc11#ECDH-ES | | | | Advanced | A128 | http://www.w3.org/2001/04 | | | |||

| Diffie | | | | | | Encrypti | KW | /xmlenc#kw-aes128 | | | |||

| -Hellma | | | | | | on | | | | | |||

| n Ephem | | | | | | Standar | | | | | |||

| eral | | | | | | d(AES) | | | | | |||

| Stat | | | | | | Key Wra | | | | | |||

| ic | | | | | | pAlgorit | | | | | |||

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

| d | W | /xmlenc#kw-aes128 | | | | 128 bi | | | | | |||

| Encryp | | | | | | t keys | | | | | |||

| tion | | | | | | AES Key | A256 | http://www.w3.org/2001/04 | | | |||

| Stand | | | | | | Wrap | KW | /xmlenc#kw-aes256 | | | |||

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

| ) Key | | | | | | musing | | | | | |||

| Wrap | | | | | | 256 bit | | | | | |||

| Algo | | | | | | keys | | | | | |||

| rithm R | | | | | | AES in | A128 | http://www.w3.org/2001/04 | AES/CBC/PKCS5Paddin | | |||

| FC 339 | | | | | | Cipher | CBC | /xmlenc#aes128-cbc | g | | |||

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

| C3394] | | | | | | Chaining | | | | | |||

| using12 | | | | | | (CBC) | | | | | |||

| 8 bitke | | | | | | mode | | | | | |||

| ys | | | | | | with | | | | | |||

| Advance | A256K | http://www.w3.org/2001/04 | TBD | | | PKCS #5 | | | | | |||

| d | W | /xmlenc#kw-aes256 | | | | padding | | | | | |||

| Encryp | | | | | | using | | | | | |||

| tion | | | | | | 128 bit | | | | | |||

| Stand | | | | | | keys | | | | | |||

| ard(AES | | | | | | AES in | A256 | http://www.w3.org/2001/04 | AES/CBC/PKCS5Paddin | | |||

| ) Key | | | | | | CBC mode | CBC | /xmlenc#aes256-cbc | g | | |||

| Wrap | | | | | | with | | | | | |||

| Algo | | | | | | PKCS #5 | | | | | |||

| rithm R | | | | | | padding | | | | | |||

| FC 339 | | | | | | using | | | | | |||

| 4 [RF | | | | | | 256 bit | | | | | |||

| C3394] | | | | | | keys | | | | | |||

| using25 | | | | | | AES in | A128 | http://www.w3.org/2009/xm | AES/GCM/NoPadding | | |||

| 6 bitke | | | | | | Galois/C | GCM | lenc11#aes128-gcm | | | |||

| ys | | | | | | ounter | | | | | |||

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

| d | BC | /xmlenc#aes128-cbc | g | | | (GCM) | | | | | |||

| Encryp | | | | | | using | | | | | |||

| tion | | | | | | 128 bit | | | | | |||

| Stand | | | | | | keys | | | | | |||

| ard(AES | | | | | | AES GCM | A256 | http://www.w3.org/2009/xm | AES/GCM/NoPadding | | |||

| ) usin | | | | | | using | GCM | lenc11#aes256-gcm | | | |||

| g 128 | | | | | | 256 bit | | | | | |||

| bitkeys | | | | | | keys | | | | | |||

| inCiph | | | | | +----------+------+---------------------------+---------------------+ | |||

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

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

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

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

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

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

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

| ding | | | | | ||||

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

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

| Encryp | | | | | ||||

| tion | | | | | ||||

| Stand | | | | | ||||

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

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

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

| bitkeys | | | | | ||||

| inCiph | | | | | ||||

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

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

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

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

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

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

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

| ding | | | | | ||||

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

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

| Encryp | | | | | ||||

| tion | | | | | ||||

| Stand | | | | | ||||

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

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

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

| bitkeys | | | | | ||||

| inGalo | | | | | ||||

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

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

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

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

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

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

| Encryp | | | | | ||||

| tion | | | | | ||||

| Stand | | | | | ||||

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

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

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

| bitkeys | | | | | ||||

| inGalo | | | | | ||||

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

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

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

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

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

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

[[ to be removed by the RFC editor before publication as an RFC ]] | ||||

-03 | ||||

o Always use a 128 bit "authentication tag" size for AES GCM, | ||||

regardless of the key size. | ||||

o Specified that use of a 128 bit IV is REQUIRED with AES CBC. It | ||||

was previously RECOMMENDED. | ||||

o Removed key size language for ECDSA algorithms, since the key size | ||||

is implied by the algorithm being used. | ||||

o Stated that the "int" key size must be the same as the hash output | ||||

size (and not larger, as was previously allowed) so that its size | ||||

is defined for key generation purposes. | ||||

o Added the "kdf" (key derivation function) header parameter to | ||||

provide crypto agility for key derivation. The default KDF | ||||

remains the Concat KDF with the SHA-256 digest function. | ||||

o Clarified that the "mod" and "exp" values are unsigned. | ||||

o Added Implementation Requirements columns to algorithm tables and | ||||

Implementation Requirements entries to algorithm registries. | ||||

o Changed AES Key Wrap to RECOMMENDED. | ||||

o Moved registries JSON Web Signature and Encryption Header | ||||

Parameters and JSON Web Signature and Encryption Type Values to | ||||

the JWS specification. | ||||

o Moved JSON Web Key Parameters registry to the JWK specification. | ||||

o Changed registration requirements from RFC Required to | ||||

Specification Required with Expert Review. | ||||

o Added Registration Template sections for defined registries. | ||||

o Added Registry Contents sections to populate registry values. | ||||

o No longer say "the UTF-8 representation of the JWS Secured Input | ||||

(which is the same as the ASCII representation)". Just call it | ||||

"the ASCII representation of the JWS Secured Input". | ||||

o Added "Collision Resistant Namespace" to the terminology section. | ||||

o Numerous editorial improvements. | ||||

-02 | -02 | |||

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

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

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

Integrity Value. | Integrity Value. | |||

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

specified key sizes. | specified key sizes. | |||

End of changes. 113 change blocks. | ||||

553 lines changed or deleted | | 1152 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/ |