draft-ietf-jose-json-web-algorithms-04.txt   draft-ietf-jose-json-web-algorithms-05.txt 
JOSE Working Group M. Jones JOSE Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track July 16, 2012 Intended status: Standards Track July 30, 2012
Expires: January 17, 2013 Expires: January 31, 2013
JSON Web Algorithms (JWA) JSON Web Algorithms (JWA)
draft-ietf-jose-json-web-algorithms-04 draft-ietf-jose-json-web-algorithms-05
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), JSON Web Encryption (JWE), and JSON Web Key (JWK) (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK)
specifications. specifications.
Status of this Memo Status of this Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 January 17, 2013. This Internet-Draft will expire on January 31, 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
skipping to change at page 2, line 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . 10 P-384 SHA-384, or ECDSA P-521 SHA-512 . . . . . . . . . . 10
3.5. Using the Algorithm "none" . . . . . . . . . . . . . . . . 11 3.5. Using the Algorithm "none" . . . . . . . . . . . . . . . . 11
3.6. Additional Digital Signature/MAC Algorithms and 3.6. Additional Digital Signature/MAC Algorithms and
Parameters . . . . . . . . . . . . . . . . . . . . . . . . 12 Parameters . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Cryptographic Algorithms for JWE . . . . . . . . . . . . . . . 12 4. Cryptographic Algorithms for JWE . . . . . . . . . . . . . . . 12
4.1. "alg" (Algorithm) Header Parameter Values for JWE . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 JWE . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3. "int" (Integrity Algorithm) Header Parameter Values 4.3. "int" (Integrity Algorithm) Header Parameter Values
for JWE . . . . . . . . . . . . . . . . . . . . . . . . . 14 for JWE . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4. "kdf" (Key Derivation Function) Header Parameter 4.4. "kdf" (Key Derivation Function) Header Parameter
Values for JWE . . . . . . . . . . . . . . . . . . . . . . 14 Values for JWE . . . . . . . . . . . . . . . . . . . . . . 15
4.5. Key Encryption with RSAES-PKCS1-V1_5 . . . . . . . . . . . 15 4.5. Key Encryption with RSAES-PKCS1-V1_5 . . . . . . . . . . . 15
4.6. Key Encryption with RSAES OAEP . . . . . . . . . . . . . . 15 4.6. Key Encryption with RSAES OAEP . . . . . . . . . . . . . . 16
4.7. Key Agreement with Elliptic Curve Diffie-Hellman 4.7. Key Encryption with AES Key Wrap . . . . . . . . . . . . . 16
Ephemeral Static (ECDH-ES) . . . . . . . . . . . . . . . . 15 4.8. Direct Encryption with a Shared Symmetric Key . . . . . . 16
4.8. Key Encryption with AES Key Wrap . . . . . . . . . . . . . 15 4.9. Key Agreement with Elliptic Curve Diffie-Hellman
4.9. Plaintext Encryption with AES CBC Mode . . . . . . . . . . 15 Ephemeral Static (ECDH-ES) . . . . . . . . . . . . . . . . 16
4.10. Plaintext Encryption with AES GCM . . . . . . . . . . . . 16 4.10. Plaintext Encryption with AES CBC Mode . . . . . . . . . . 17
4.11. Integrity Calculation with HMAC SHA-256, HMAC SHA-384, 4.11. Plaintext Encryption with AES GCM . . . . . . . . . . . . 17
or HMAC SHA-512 . . . . . . . . . . . . . . . . . . . . . 16 4.12. Integrity Calculation with HMAC SHA-256, HMAC SHA-384,
4.12. Key Derivation with Concat KDF and SHA-256, SHA-384, or HMAC SHA-512 . . . . . . . . . . . . . . . . . . . . . 17
or SHA-512 . . . . . . . . . . . . . . . . . . . . . . . . 16 4.13. Key Derivation with Concat KDF and SHA-256, SHA-384,
4.13. Additional Encryption Algorithms and Parameters . . . . . 17 or SHA-512 . . . . . . . . . . . . . . . . . . . . . . . . 18
5. Cryptographic Algorithms for JWK . . . . . . . . . . . . . . . 18 4.14. Additional Encryption Algorithms and Parameters . . . . . 18
5.1. "alg" (Algorithm Family) Parameter Values for JWK . . . . 18 5. Cryptographic Algorithms for JWK . . . . . . . . . . . . . . . 19
5.2. JWK Parameters for Elliptic Curve Keys . . . . . . . . . . 18 5.1. "alg" (Algorithm Family) Parameter Values for JWK . . . . 19
5.2.1. "crv" (Curve) Parameter . . . . . . . . . . . . . . . 18 5.2. JWK Parameters for Elliptic Curve Keys . . . . . . . . . . 19
5.2.2. "x" (X Coordinate) Parameter . . . . . . . . . . . . . 19 5.2.1. "crv" (Curve) Parameter . . . . . . . . . . . . . . . 20
5.2.3. "y" (Y Coordinate) Parameter . . . . . . . . . . . . . 19 5.2.2. "x" (X Coordinate) Parameter . . . . . . . . . . . . . 20
5.3. JWK Parameters for RSA Keys . . . . . . . . . . . . . . . 19 5.2.3. "y" (Y Coordinate) Parameter . . . . . . . . . . . . . 20
5.3.1. "mod" (Modulus) Parameter . . . . . . . . . . . . . . 19 5.3. JWK Parameters for RSA Keys . . . . . . . . . . . . . . . 20
5.3.2. "exp" (Exponent) Parameter . . . . . . . . . . . . . . 20 5.3.1. "mod" (Modulus) Parameter . . . . . . . . . . . . . . 20
5.3.2. "exp" (Exponent) Parameter . . . . . . . . . . . . . . 21
5.4. Additional Key Algorithm Families and Parameters . . . . . 20 5.4. Additional Key Algorithm Families and Parameters . . . . . 21
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
6.1. JSON Web Signature and Encryption Algorithms Registry . . 21 6.1. JSON Web Signature and Encryption Algorithms Registry . . 22
6.1.1. Registration Template . . . . . . . . . . . . . . . . 21 6.1.1. Registration Template . . . . . . . . . . . . . . . . 22
6.1.2. Initial Registry Contents . . . . . . . . . . . . . . 22 6.1.2. Initial Registry Contents . . . . . . . . . . . . . . 23
6.2. JSON Web Key Algorithm Families Registry . . . . . . . . . 26 6.2. JSON Web Key Algorithm Families Registry . . . . . . . . . 28
6.2.1. Registration Template . . . . . . . . . . . . . . . . 27 6.2.1. Registration Template . . . . . . . . . . . . . . . . 28
6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 27 6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 29
6.3. JSON Web Key Parameters Registration . . . . . . . . . . . 28 6.3. JSON Web Key Parameters Registration . . . . . . . . . . . 29
6.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 28 6.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 29 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.1. Normative References . . . . . . . . . . . . . . . . . . . 30 9.1. Normative References . . . . . . . . . . . . . . . . . . . 33
9.2. Informative References . . . . . . . . . . . . . . . . . . 32 9.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. Digital Signature/MAC Algorithm Identifier Appendix A. Digital Signature/MAC Algorithm Identifier
Cross-Reference . . . . . . . . . . . . . . . . . . . 33 Cross-Reference . . . . . . . . . . . . . . . . . . . 35
Appendix B. Encryption Algorithm Identifier Cross-Reference . . . 35 Appendix B. Encryption Algorithm Identifier Cross-Reference . . . 37
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 37 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 39
Appendix D. Document History . . . . . . . . . . . . . . . . . . 38 Appendix D. Document History . . . . . . . . . . . . . . . . . . 40
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 40 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43
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], JSON Web Encryption (JWE) [JWE], and JSON Web Key (JWK) (JWS) [JWS], JSON Web Encryption (JWE) [JWE], and JSON Web Key (JWK)
[JWK] specifications. All these specifications utilize JavaScript [JWK] specifications. All these specifications utilize JavaScript
Object Notation (JSON) [RFC4627] based data structures. This Object Notation (JSON) [RFC4627] based data structures. This
specification also describes the semantics and operations that are specification also describes the semantics and operations that are
specific to these algorithms and algorithm families. specific to these algorithms and algorithm families.
skipping to change at page 12, line 42 skipping to change at page 13, line 5
(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 | Implementation | | alg Parameter | Key Encryption or Agreement | Implementation |
| Parameter | Algorithm | Requirements | | Value | Algorithm | Requirements |
| Value | | | +----------------+---------------------------------+----------------+
+-----------+--------------------------------------+----------------+ | RSA1_5 | RSAES-PKCS1-V1_5 [RFC3447] | REQUIRED |
| RSA1_5 | RSAES-PKCS1-V1_5 [RFC3447] | REQUIRED | | RSA-OAEP | RSAES using Optimal Asymmetric | OPTIONAL |
| RSA-OAEP | RSAES using Optimal Asymmetric | OPTIONAL | | | Encryption Padding (OAEP) | |
| | Encryption Padding (OAEP) [RFC3447], | | | | [RFC3447], with the default | |
| | with the default parameters | | | | parameters specified by RFC | |
| | specified by RFC 3447 in Section | | | | 3447 in Section A.2.1 | |
| | A.2.1 | | | A128KW | Advanced Encryption Standard | RECOMMENDED |
| ECDH-ES | Elliptic Curve Diffie-Hellman | RECOMMENDED+ | | | (AES) Key Wrap Algorithm | |
| | Ephemeral Static [RFC6090], and | | | | [RFC3394] using 128 bit keys | |
| | using the Concat KDF, as defined in | | | A256KW | AES Key Wrap Algorithm using | RECOMMENDED |
| | Section 5.8.1 of [NIST.800-56A], | | | | 256 bit keys | |
| | where the Digest Method is SHA-256 | | | dir | Direct use of a shared | RECOMMENDED |
| | and all OtherInfo parameters are the | | | | symmetric key as the Content | |
| | empty bit string | | | | Master Key (CMK) for the block | |
| A128KW | Advanced Encryption Standard (AES) | RECOMMENDED | | | encryption step (rather than | |
| | Key Wrap Algorithm [RFC3394] using | | | | using the symmetric key to wrap | |
| | 128 bit keys | | | | the CMK) | |
| A256KW | AES Key Wrap Algorithm using 256 bit | RECOMMENDED | | ECDH-ES | Elliptic Curve Diffie-Hellman | RECOMMENDED+ |
| | keys | | | | Ephemeral Static [RFC6090] key | |
+-----------+--------------------------------------+----------------+ | | agreement using the Concat KDF, | |
| | as defined in Section 5.8.1 of | |
| | [NIST.800-56A], where the | |
| | Digest Method is SHA-256 and | |
| | all OtherInfo parameters are | |
| | the empty bit string, with the | |
| | agreed-upon key being used | |
| | directly as the Content Master | |
| | Key (CMK) (rather than being | |
| | used to wrap the CMK) | |
| ECDH-ES+A128KW | Elliptic Curve Diffie-Hellman | RECOMMENDED |
| | Ephemeral Static key agreement | |
| | per "ECDH-ES", but where the | |
| | agreed-upon key is used to wrap | |
| | the Content Master Key (CMK) | |
| | with the "A128KW" function | |
| | (rather than being used | |
| | directly as the CMK) | |
| ECDH-ES+A256KW | Elliptic Curve Diffie-Hellman | RECOMMENDED |
| | Ephemeral Static key agreement | |
| | per "ECDH-ES", but where the | |
| | agreed-upon key is used to wrap | |
| | the Content Master Key (CMK) | |
| | with the "A256KW" function | |
| | (rather than being used | |
| | directly as the CMK) | |
+----------------+---------------------------------+----------------+
The use of "+" in the Implementation Requirements indicates that the The use of "+" in the Implementation Requirements indicates that the
requirement strength is likely to be increased in a future version of requirement strength is likely to be increased in a future version of
the specification. 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
skipping to change at page 14, line 43 skipping to change at page 15, line 36
The table below is the set of "kdf" (key derivation function) header The table below is the set of "kdf" (key derivation function) header
parameter values defined by this specification for use with JWE. parameter values defined by this specification for use with JWE.
+-----------+--------------------------------------+----------------+ +-----------+--------------------------------------+----------------+
| kdf | Algorithm | Implementation | | kdf | Algorithm | Implementation |
| Parameter | | Requirements | | Parameter | | Requirements |
| Value | | | | Value | | |
+-----------+--------------------------------------+----------------+ +-----------+--------------------------------------+----------------+
| CS256 | Concat KDF, as defined in Section | REQUIRED | | CS256 | Concat KDF, as defined in Section | REQUIRED |
| | 5.8.1 of [NIST.800-56A], with | | | | 5.8.1 of [NIST.800-56A], with | |
| | parameters per Section 4.12, using | | | | parameters per Section 4.13, using | |
| | SHA-256 as the digest method | | | | SHA-256 as the digest method | |
| CS384 | Concat KDF with parameters per | OPTIONAL | | CS384 | Concat KDF with parameters per | OPTIONAL |
| | Section 4.12, using SHA-384 as the | | | | Section 4.13, using SHA-384 as the | |
| | digest method | | | | digest method | |
| CS512 | Concat KDF with parameters per | OPTIONAL | | CS512 | Concat KDF with parameters per | OPTIONAL |
| | Section 4.12, using SHA-512 as the | | | | Section 4.13, using SHA-512 as the | |
| | digest method | | | | digest method | |
+-----------+--------------------------------------+----------------+ +-----------+--------------------------------------+----------------+
4.5. Key Encryption with RSAES-PKCS1-V1_5 4.5. Key Encryption with RSAES-PKCS1-V1_5
This section defines the specifics of encrypting a JWE CMK with This section defines the specifics of encrypting a JWE CMK with
RSAES-PKCS1-V1_5 [RFC3447]. The "alg" header parameter value RSAES-PKCS1-V1_5 [RFC3447]. The "alg" header parameter value
"RSA1_5" is used in this case. "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.6. Key Encryption with RSAES OAEP 4.6. Key Encryption with RSAES OAEP
This section defines the specifics of encrypting a JWE CMK with RSAES This section defines the specifics of encrypting a JWE CMK with RSAES
using Optimal Asymmetric Encryption Padding (OAEP) [RFC3447], with using Optimal Asymmetric Encryption Padding (OAEP) [RFC3447], with
the default parameters specified by RFC 3447 in Section A.2.1. The the default parameters specified by RFC 3447 in Section A.2.1. The
"alg" header parameter value "RSA-OAEP" is used 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.7. Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static 4.7. Key Encryption with AES Key Wrap
This section defines the specifics of encrypting a JWE CMK with the
Advanced Encryption Standard (AES) Key Wrap Algorithm [RFC3394] using
128 or 256 bit keys. The "alg" header parameter values "A128KW" or
"A256KW" are used in this case.
4.8. Direct Encryption with a Shared Symmetric Key
This section defines the specifics of directly performing symmetric
key encryption without performing a key wrapping step. In this case,
the shared symmetric key is used directly as the Content Master Key
(CMK) value for the "enc" algorithm. An empty byte array is used as
the JWE Encrypted Key value. The "alg" header parameter value "dir"
is used in this case.
4.9. 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 key agreement with Elliptic
Elliptic Curve Diffie-Hellman Ephemeral Static [RFC6090], and using Curve Diffie-Hellman Ephemeral Static [RFC6090], and using the Concat
the Concat KDF, as defined in Section 5.8.1 of [NIST.800-56A], where KDF, as defined in Section 5.8.1 of [NIST.800-56A], where the Digest
the Digest Method is SHA-256 and all OtherInfo parameters are the Method is SHA-256 and all OtherInfo parameters are the empty bit
empty bit string. The "alg" header parameter value "ECDH-ES" is used string. The key agreement result can be used in one of two ways: (1)
in this case. directly as the Content Master Key (CMK) for the "enc" algorithm, or
(2) as a symmetric key used to wrap the CMK with either the "A128KW"
or "A256KW" algorithms. The "alg" header parameter values "ECDH-ES",
"ECDH-ES+A128KW", and "ECDH-ES+A256KW" are respectively used in this
case.
The output of the Concat KDF MUST be a key of the same length as that In the direct case, the output of the Concat KDF MUST be a key of the
used by the "enc" algorithm. same length as that used by the "enc" algorithm; in this case, the
empty byte array is used as the JWE Encrypted Key value. In the key
wrap case, the output of the Concat KDF MUST be a key of the length
needed for the specified key wrap algorithm, either 128 or 256 bits
respectively.
A new "epk" (ephemeral public key) value MUST be generated for each A new "epk" (ephemeral public key) value MUST be generated for each
key agreement transaction. key agreement transaction.
4.8. Key Encryption with AES Key Wrap 4.10. Plaintext Encryption with AES CBC Mode
This section defines the specifics of encrypting a JWE CMK with the
Advanced Encryption Standard (AES) Key Wrap Algorithm [RFC3394] using
128 or 256 bit keys. The "alg" header parameter values "A128KW" or
"A256KW" are used in this case.
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 with PKCS #5 padding [AES] [NIST.800-38A] using 128 or 256 (CBC) mode with PKCS #5 padding [AES] [NIST.800-38A] using 128 or 256
bit keys. The "enc" header parameter values "A128CBC" or "A256CBC" bit keys. The "enc" header parameter values "A128CBC" or "A256CBC"
are used in this case. are used in this case.
Use of an initialization vector of size 128 bits is REQUIRED with Use of an initialization vector of size 128 bits is REQUIRED with
this algorithm. this algorithm.
4.10. Plaintext Encryption with AES GCM 4.11. 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)
[AES] [NIST.800-38D] using 128 or 256 bit keys. The "enc" header [AES] [NIST.800-38D] using 128 or 256 bit keys. The "enc" header
parameter values "A128GCM" or "A256GCM" are used in this case. parameter values "A128GCM" or "A256GCM" are used in this case.
Use of an initialization vector of size 96 bits is REQUIRED with this Use of an initialization vector of size 96 bits is REQUIRED with this
algorithm. algorithm.
The "additional authenticated data" parameter is used to secure the The "additional authenticated data" parameter is used to secure the
header and key values, as specified for AEAD algorithms in Section 5 header and key values, as specified for AEAD algorithms in Section 5
of [JWE]. of [JWE].
The requested size of the "authentication tag" output MUST be 128 The requested size of the "authentication tag" output MUST be 128
bits, regardless of the key size. 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.11. Integrity Calculation with HMAC SHA-256, HMAC SHA-384, or HMAC 4.12. 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 [SHS]. Other than with HMAC SHA-256, HMAC SHA-384, or HMAC SHA-512 [SHS]. Other than
as stated below, these computations are performed identically to as stated below, these computations are performed identically to
those specified in Section 3.2. 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") MUST be used with this algorithm. "HS256") MUST be used with this algorithm.
Per Section 9 of [JWE], the JWS Secured Input value used contains the Per Section 9 of [JWE], the JWS Secured Input value used contains the
header, encrypted key, and ciphertext. header, encrypted key, and ciphertext.
4.12. Key Derivation with Concat KDF and SHA-256, SHA-384, or SHA-512 4.13. 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. The key derivation process derives CEK and CIK values from the CMK.
It uses as a primitive a Key Derivation Function (KDF) which It uses as a primitive a Key Derivation Function (KDF) which
notionally takes three arguments: notionally takes three arguments:
MasterKey: The master key used to compute the individual use keys MasterKey: The master key used to compute the individual use keys
Label: The use key label, used to differentiate individual use keys Label: The use key label, used to differentiate individual use keys
Length: The desired length of the use key Length: The desired length of the use key
This section defines the specifics of using the Concat KDF, as 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 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 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 the Label, and the remaining OtherInfo parameters are the empty bit
string. string.
skipping to change at page 17, line 30 skipping to change at page 18, line 39
To compute the CEK from the CMK, the ASCII label "Encryption" ([69, 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 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. size for the "enc" algorithm as the CEK desired key length.
To compute the CIK from the CMK, the ASCII label "Integrity" ([73, 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 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") key size for the "int" algorithm (for instance, 256 bits for "HS256")
as the CIK desired key length. as the CIK desired key length.
4.13. Additional Encryption Algorithms and Parameters 4.14. 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
registered in the IANA JSON Web Signature and Encryption Algorithms registered in the IANA JSON Web Signature and Encryption Algorithms
registry Section 6.1 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
skipping to change at page 24, line 40 skipping to change at page 25, line 46
o Algorithm Name: "RSA-OAEP" o Algorithm Name: "RSA-OAEP"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: OPTIONAL o Implementation Requirements: OPTIONAL
o Change Controller: IETF o Change Controller: IETF
o Specification Document(s): Section 4.1 of [[ this document ]] 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: "dir"
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: "ECDH-ES" o Algorithm Name: "ECDH-ES"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: RECOMMENDED+ o Implementation Requirements: RECOMMENDED+
o Change Controller: IETF o Change Controller: IETF
o Specification Document(s): Section 4.1 of [[ this document ]] o Specification Document(s): Section 4.1 of [[ this document ]]
o Algorithm Name: "A128KW"
o Algorithm Name: "ECDH-ES+A128KW"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: RECOMMENDED o Implementation Requirements: RECOMMENDED
o Change Controller: IETF o Change Controller: IETF
o Specification Document(s): Section 4.1 of [[ this document ]] o Specification Document(s): Section 4.1 of [[ this document ]]
o Algorithm Name: "A256KW" o Algorithm Name: "ECDH-ES+A256KW"
o Algorithm Usage Location(s): "alg" o Algorithm Usage Location(s): "alg"
o Implementation Requirements: RECOMMENDED o Implementation Requirements: RECOMMENDED
o Change Controller: IETF o Change Controller: IETF
o Specification Document(s): Section 4.1 of [[ this document ]] o Specification Document(s): Section 4.1 of [[ this document ]]
o Algorithm Name: "A128CBC" o Algorithm Name: "A128CBC"
o Algorithm Usage Location(s): "enc" o Algorithm Usage Location(s): "enc"
skipping to change at page 30, line 15 skipping to change at page 32, line 10
o Should we use the "alg" value as the AlgorithmID input to the o Should we use the "alg" value as the AlgorithmID input to the
Concat KDF when doing key agreement? Or is an AlgorithmID value Concat KDF when doing key agreement? Or is an AlgorithmID value
unnecessary in the way that we are using Concat for key agreement? unnecessary in the way that we are using Concat for key agreement?
o Similarly, should we use a combination of the "enc" and "int" o Similarly, should we use a combination of the "enc" and "int"
values as the AlgorithmID input to the Concat KDF when doing key values as the AlgorithmID input to the Concat KDF when doing key
derivation? Or is an AlgorithmID value unnecessary in the way derivation? Or is an AlgorithmID value unnecessary in the way
that we are using Concat for key derivation? that we are using Concat for key derivation?
o Do we want to add the output key length to the Concat KDF input
parameters?
o Do we need non-empty PartyUInfo and PartyVInfo values when using o Do we need non-empty PartyUInfo and PartyVInfo values when using
the Concat KDF for key agreement? Or given that we already the Concat KDF for key agreement? Or given that we already
require the use of a random unique Ephemeral Public Key (EPK), is require the use of a random unique Ephemeral Public Key (EPK), is
this superfluous, as duplicate keys will not be generated unless a this superfluous, as duplicate keys will not be generated unless a
duplicate EPK is used? If we do decide we need PartyUInfo and duplicate EPK is used? If we do decide we need PartyUInfo and
PartyVInfo values, how can we dynamically generate them from PartyVInfo values, how can we dynamically generate them from
information already carried in the header, rather than requiring information already carried in the header, rather than requiring
that they be explicitly passed as header parameters? that they be explicitly passed as header parameters?
o Similarly, do we need non-empty PartyUInfo and PartyVInfo values o Similarly, do we need non-empty PartyUInfo and PartyVInfo values
when using the Concat KDF for key derivation? Or given that we when using the Concat KDF for key derivation? Or given that we
already require the use of a random unique Content Master Key already require the use of a random unique Content Master Key
(CMK), is this superfluous, as duplicate keys will not be (CMK), is this superfluous, as duplicate keys will not be
generated unless a duplicate CMK is used? If we do decide we need generated unless a duplicate CMK is used? If we do decide we need
PartyUInfo and PartyVInfo values, how can we dynamically generate PartyUInfo and PartyVInfo values, how can we dynamically generate
them from information already carried in the header, rather than them from information already carried in the header, rather than
requiring that they be explicitly passed as header parameters? requiring that they be explicitly passed as header parameters?
o We use the same secret multiple times with the Concat KDF with
different parameters to generate multiple derived keys. Do we
want to continue this practice or instead use the KDF once to
generate a big enough byte array for all derived keys, and use
different parts of the byte array for each key?
o Do we want to add AES ECB as a (non-authenticated) key wrap o Do we want to add AES ECB as a (non-authenticated) key wrap
algorithm? Is there any problem with doing key wrap without an algorithm? Is there any problem with doing key wrap without an
integrity check, given that a separate integrity check already integrity check, given that a separate integrity check already
covers the wrapped key? covers the wrapped key?
o Do we want to add the ability to perform symmetric encryption o Do we want the ability to perform symmetric encryption directly
directly with a shared key, without using a CMK? This would save with a shared key, without using a separate CMK? This would save
space and time in the single recipient case. It would also be space and time in the single recipient case. It would also be
parallel to the current treatment of key agreement, which doesn't parallel to this option for key agreement, which doesn't use a
use a CMK. separate CMK.
o Do we want the ability to perform symmetric encryption directly
with an agreed upon key, without using a separate CMK? The
arguments for this parallel those for direct encryption using a
shared key.
9. References 9. References
9.1. Normative References 9.1. Normative References
[AES] National Institute of Standards and Technology (NIST), [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 [DSS] National Institute of Standards and Technology, "Digital
skipping to change at page 33, line 7 skipping to change at page 35, line 15
[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 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
July 2005. July 2005.
[W3C.CR-xmldsig-core2-20120124] [W3C.CR-xmldsig-core2-20120124]
Reagle, J., Hirsch, F., Cantor, S., Roessler, T., Solo, D., Datta, P., Hirsch, F., Cantor, S., Reagle, J.,
Eastlake, D., Yiu, K., Solo, D., and P. Datta, "XML Roessler, T., Eastlake, D., and K. Yiu, "XML Signature
Signature Syntax and Processing Version 2.0", World Wide Syntax and Processing Version 2.0", World Wide Web
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., Hirsch, F., and T. Roessler, 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]
skipping to change at page 35, line 42 skipping to change at page 38, line 4
| algo | | | | | | algo | | | | |
| rithm | | | | | | rithm | | | | |
+-------+-----+----------------------------+----------+-------------+ +-------+-----+----------------------------+----------+-------------+
Appendix B. Encryption Algorithm Identifier Cross-Reference Appendix B. Encryption Algorithm Identifier Cross-Reference
This appendix contains a table cross-referencing the "alg" This appendix contains a table cross-referencing the "alg"
(algorithm) and "enc" (encryption method) values used in this (algorithm) and "enc" (encryption method) values used in this
specification with the equivalent identifiers used by other standards specification with the equivalent identifiers used by other standards
and software packages. See XML Encryption and software packages. See XML Encryption
[W3C.REC-xmlenc-core-20021210], XML Encryption 1.1 [W3C.REC-xmlenc-core-20021210], XML Encryption 1.1
[W3C.CR-xmlenc-core1-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.
+----------+------+---------------------------+---------------------+ +----------+------+---------------------------+---------------------+
| Algorith | JWE | XML ENC | JCA | | Algorith | JWE | XML ENC | JCA |
| m | | | | | m | | | |
+----------+------+---------------------------+---------------------+ +----------+------+---------------------------+---------------------+
| RSAES-PK | RSA1 | http://www.w3.org/2001/04 | RSA/None/PKCS1Paddi | | RSAES-PK | RSA1 | http://www.w3.org/2001/04 | RSA/ECB/PKCS1Paddin |
| CS1-V1_5 | _5 | /xmlenc#rsa-1_5 | ng | | CS1-V1_5 | _5 | /xmlenc#rsa-1_5 | g |
| RSAES | RSA- | http://www.w3.org/2001/04 | RSA/None/OAEPWithSH | | RSAES | RSA- | http://www.w3.org/2001/04 | RSA/ECB/OAEPWithSHA |
| using | OAEP | /xmlenc#rsa-oaep-mgf1p | A-1AndMGF1Padding | | using | OAEP | /xmlenc#rsa-oaep-mgf1p | -1AndMGF1Padding |
| Optimal | | | | | Optimal | | | |
| Asymmetr | | | | | Asymmetr | | | |
| ic | | | | | ic | | | |
| Encrypt | | | | | Encrypt | | | |
| ion | | | | | ion | | | |
| Paddin | | | | | Paddin | | | |
| g (OAEP) | | | | | g (OAEP) | | | |
| Elliptic | ECDH | http://www.w3.org/2009/xm | | | Elliptic | ECDH | http://www.w3.org/2009/xm | |
| Curve | -ES | lenc11#ECDH-ES | | | Curve | -ES | lenc11#ECDH-ES | |
| Diffie-H | | | | | Diffie-H | | | |
skipping to change at page 38, line 9 skipping to change at page 40, line 9
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 ]] [[ to be removed by the RFC editor before publication as an RFC ]]
-05
o Support both direct encryption using a shared or agreed upon
symmetric key, and the use of a shared or agreed upon symmetric
key to key wrap the CMK. Specifically, added the "alg" values
"dir", "ECDH-ES+A128KW", and "ECDH-ES+A256KW" to finish filling in
this set of capabilities.
o Updated open issues.
-04 -04
o Added text requiring that any leading zero bytes be retained in o Added text requiring that any leading zero bytes be retained in
base64url encoded key value representations for fixed-length base64url encoded key value representations for fixed-length
values. values.
o Added this language to Registration Templates: "This name is case o Added this language to Registration Templates: "This name is case
sensitive. Names that match other registered names in a case sensitive. Names that match other registered names in a case
insensitive manner SHOULD NOT be accepted." insensitive manner SHOULD NOT be accepted."
 End of changes. 33 change blocks. 
111 lines changed or deleted 209 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/