draft-ietf-jose-json-web-algorithms-29.txt   draft-ietf-jose-json-web-algorithms-30.txt 
JOSE Working Group M. Jones JOSE Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track June 20, 2014 Intended status: Standards Track July 1, 2014
Expires: December 22, 2014 Expires: January 2, 2015
JSON Web Algorithms (JWA) JSON Web Algorithms (JWA)
draft-ietf-jose-json-web-algorithms-29 draft-ietf-jose-json-web-algorithms-30
Abstract Abstract
The JSON Web Algorithms (JWA) specification registers cryptographic The JSON Web Algorithms (JWA) specification registers 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. It defines several IANA registries for these specifications. It defines several IANA registries for these
identifiers. identifiers.
Status of this Memo Status of this Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 December 22, 2014. This Internet-Draft will expire on January 2, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 4, line 9 skipping to change at page 4, line 9
8.5. Plaintext JWS Security Considerations . . . . . . . . . . 49 8.5. Plaintext JWS Security Considerations . . . . . . . . . . 49
8.6. Denial of Service Attacks . . . . . . . . . . . . . . . . 50 8.6. Denial of Service Attacks . . . . . . . . . . . . . . . . 50
8.7. Reusing Key Material when Encrypting Keys . . . . . . . . 50 8.7. Reusing Key Material when Encrypting Keys . . . . . . . . 50
8.8. Password Considerations . . . . . . . . . . . . . . . . . 50 8.8. Password Considerations . . . . . . . . . . . . . . . . . 50
8.9. Key Entropy . . . . . . . . . . . . . . . . . . . . . . . 51 8.9. Key Entropy . . . . . . . . . . . . . . . . . . . . . . . 51
8.10. Differences between Digital Signatures and MACs . . . . . 51 8.10. Differences between Digital Signatures and MACs . . . . . 51
8.11. Using Matching Algorithm Strengths . . . . . . . . . . . . 51 8.11. Using Matching Algorithm Strengths . . . . . . . . . . . . 51
8.12. Adaptive Chosen-Ciphertext Attacks . . . . . . . . . . . . 51 8.12. Adaptive Chosen-Ciphertext Attacks . . . . . . . . . . . . 51
8.13. Timing Attacks . . . . . . . . . . . . . . . . . . . . . . 51 8.13. Timing Attacks . . . . . . . . . . . . . . . . . . . . . . 51
8.14. RSA Private Key Representations and Blinding . . . . . . . 51 8.14. RSA Private Key Representations and Blinding . . . . . . . 51
9. Internationalization Considerations . . . . . . . . . . . . . 51 9. Internationalization Considerations . . . . . . . . . . . . . 52
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
10.1. Normative References . . . . . . . . . . . . . . . . . . . 52 10.1. Normative References . . . . . . . . . . . . . . . . . . . 52
10.2. Informative References . . . . . . . . . . . . . . . . . . 53 10.2. Informative References . . . . . . . . . . . . . . . . . . 53
Appendix A. Algorithm Identifier Cross-Reference . . . . . . . . 55 Appendix A. Algorithm Identifier Cross-Reference . . . . . . . . 55
A.1. Digital Signature/MAC Algorithm Identifier A.1. Digital Signature/MAC Algorithm Identifier
Cross-Reference . . . . . . . . . . . . . . . . . . . . . 55 Cross-Reference . . . . . . . . . . . . . . . . . . . . . 55
A.2. Key Management Algorithm Identifier Cross-Reference . . . 56 A.2. Key Management Algorithm Identifier Cross-Reference . . . 56
A.3. Content Encryption Algorithm Identifier Cross-Reference . 57 A.3. Content Encryption Algorithm Identifier Cross-Reference . 57
Appendix B. Test Cases for AES_CBC_HMAC_SHA2 Algorithms . . . . . 57 Appendix B. Test Cases for AES_CBC_HMAC_SHA2 Algorithms . . . . . 57
B.1. Test Cases for AES_128_CBC_HMAC_SHA_256 . . . . . . . . . 58 B.1. Test Cases for AES_128_CBC_HMAC_SHA_256 . . . . . . . . . 58
skipping to change at page 18, line 46 skipping to change at page 18, line 46
Ephemeral-Static mode in RFC 2631) and the "apv" field SHOULD NOT be Ephemeral-Static mode in RFC 2631) and the "apv" field SHOULD NOT be
present. present.
See Appendix C for an example key agreement computation using this See Appendix C for an example key agreement computation using this
method. method.
4.7. Key Encryption with AES GCM 4.7. Key Encryption with AES GCM
This section defines the specifics of encrypting a JWE Content This section defines the specifics of encrypting a JWE Content
Encryption Key (CEK) with Advanced Encryption Standard (AES) in Encryption Key (CEK) with Advanced Encryption Standard (AES) in
Galois/Counter Mode (GCM) [AES] [NIST.800-38D]. Galois/Counter Mode (GCM) [AES, NIST.800-38D].
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. The Initialization Vector is represented in base64url algorithm. The Initialization Vector is represented in base64url
encoded form as the "iv" (initialization vector) Header Parameter encoded form as the "iv" (initialization vector) Header Parameter
value. value.
The Additional Authenticated Data value used is the empty octet The Additional Authenticated Data value used is the empty octet
string. string.
The requested size of the Authentication Tag output MUST be 128 bits, The requested size of the Authentication Tag output MUST be 128 bits,
skipping to change at page 21, line 9 skipping to change at page 21, line 9
The "p2s" (PBES2 salt input) Header Parameter encodes a Salt Input The "p2s" (PBES2 salt input) Header Parameter encodes a Salt Input
value, which is used as part of the PBKDF2 salt value. The "p2s" value, which is used as part of the PBKDF2 salt value. The "p2s"
value is BASE64URL(Salt Input). This Header Parameter MUST be value is BASE64URL(Salt Input). This Header Parameter MUST be
present and MUST be understood and processed by implementations when present and MUST be understood and processed by implementations when
these algorithms are used. these algorithms are used.
The salt expands the possible keys that can be derived from a given The salt expands the possible keys that can be derived from a given
password. A Salt Input value containing 8 or more octets MUST be password. A Salt Input value containing 8 or more octets MUST be
used. A new Salt Input value MUST be generated randomly for every used. A new Salt Input value MUST be generated randomly for every
encryption operation; see [RFC4086] for considerations on generating encryption operation; see RFC 4086 [RFC4086] for considerations on
random values. The salt value used is (UTF8(Alg) || 0x00 || Salt generating random values. The salt value used is (UTF8(Alg) || 0x00
Input), where Alg is the "alg" Header Parameter value. || Salt Input), where Alg is the "alg" Header Parameter value.
4.8.1.2. "p2c" (PBES2 count) Parameter 4.8.1.2. "p2c" (PBES2 count) Parameter
The "p2c" (PBES2 count) Header Parameter contains the PBKDF2 The "p2c" (PBES2 count) Header Parameter contains the PBKDF2
iteration count, represented as a positive integer. This Header iteration count, represented as a positive integer. This Header
Parameter MUST be present and MUST be understood and processed by Parameter MUST be present and MUST be understood and processed by
implementations when these algorithms are used. implementations when these algorithms are used.
The iteration count adds computational expense, ideally compounded by The iteration count adds computational expense, ideally compounded by
the possible range of keys introduced by the salt. A minimum the possible range of keys introduced by the salt. A minimum
skipping to change at page 22, line 30 skipping to change at page 22, line 30
Ciphertext and JWE Authentication Tag values. Ciphertext and JWE Authentication Tag values.
See Appendix A.3 for a table cross-referencing the JWE "enc" See Appendix A.3 for a table cross-referencing the JWE "enc"
(encryption algorithm) values defined in this specification with the (encryption algorithm) values defined in this specification with the
equivalent identifiers used by other standards and software packages. equivalent identifiers used by other standards and software packages.
5.2. AES_CBC_HMAC_SHA2 Algorithms 5.2. AES_CBC_HMAC_SHA2 Algorithms
This section defines a family of authenticated encryption algorithms This section defines a family of authenticated encryption algorithms
built using a composition of Advanced Encryption Standard (AES) in built using a composition of Advanced Encryption Standard (AES) in
Cipher Block Chaining (CBC) mode with PKCS #7 padding [AES] Cipher Block Chaining (CBC) mode with PKCS #7 padding [AES,
[NIST.800-38A] operations and HMAC [RFC2104] [SHS] operations. This NIST.800-38A] operations and HMAC [RFC2104, SHS] operations. This
algorithm family is called AES_CBC_HMAC_SHA2. It also defines three algorithm family is called AES_CBC_HMAC_SHA2. It also defines three
instances of this family, the first using 128 bit CBC keys and HMAC instances of this family, the first using 128 bit CBC keys and HMAC
SHA-256, the second using 192 bit CBC keys and HMAC SHA-384, and the SHA-256, the second using 192 bit CBC keys and HMAC SHA-384, and the
third using 256 bit CBC keys and HMAC SHA-512. Test cases for these third using 256 bit CBC keys and HMAC SHA-512. Test cases for these
algorithms can be found in Appendix B. algorithms can be found in Appendix B.
These algorithms are based upon Authenticated Encryption with AES-CBC These algorithms are based upon Authenticated Encryption with AES-CBC
and HMAC-SHA [I-D.mcgrew-aead-aes-cbc-hmac-sha2], performing the same and HMAC-SHA [I-D.mcgrew-aead-aes-cbc-hmac-sha2], performing the same
cryptographic computations, but with the Initialization Vector and cryptographic computations, but with the Initialization Vector and
Authentication Tag values remaining separate, rather than being Authentication Tag values remaining separate, rather than being
skipping to change at page 27, line 21 skipping to change at page 27, line 21
| A192CBC-HS384 | AES_192_CBC_HMAC_SHA_384 authenticated encryption | | A192CBC-HS384 | AES_192_CBC_HMAC_SHA_384 authenticated encryption |
| | algorithm, as defined in Section 5.2.4 | | | algorithm, as defined in Section 5.2.4 |
| A256CBC-HS512 | AES_256_CBC_HMAC_SHA_512 authenticated encryption | | A256CBC-HS512 | AES_256_CBC_HMAC_SHA_512 authenticated encryption |
| | algorithm, as defined in Section 5.2.5 | | | algorithm, as defined in Section 5.2.5 |
+---------------+---------------------------------------------------+ +---------------+---------------------------------------------------+
5.3. Content Encryption with AES GCM 5.3. Content Encryption with AES GCM
This section defines the specifics of performing authenticated This section defines the specifics of performing authenticated
encryption with Advanced Encryption Standard (AES) in Galois/Counter encryption with Advanced Encryption Standard (AES) in Galois/Counter
Mode (GCM) [AES] [NIST.800-38D]. Mode (GCM) [AES, NIST.800-38D].
The CEK is used as the encryption key. The CEK is used as the encryption key.
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 requested size of the Authentication Tag output MUST be 128 bits, The requested size of the Authentication Tag output MUST be 128 bits,
regardless of the key size. regardless of the key size.
The following "enc" (encryption algorithm) Header Parameter values The following "enc" (encryption algorithm) Header Parameter values
skipping to change at page 33, line 5 skipping to change at page 33, line 5
The "k" (key value) member contains the value of the symmetric (or The "k" (key value) member contains the value of the symmetric (or
other single-valued) key. It is represented as the base64url other single-valued) key. It is represented as the base64url
encoding of the octet sequence containing the key value. encoding of the octet sequence containing the key value.
7. IANA Considerations 7. IANA Considerations
The following registration procedure is used for all the registries The following registration procedure is used for all the registries
established by this specification. established by this specification.
Values are registered with a Specification Required [RFC5226] after a Values are registered on a Specification Required [RFC5226] basis
two-week review period on the [TBD]@ietf.org mailing list, on the after a two-week review period on the [TBD]@ietf.org mailing list, on
advice of one or more Designated Experts. However, to allow for the the advice of one or more Designated Experts. However, to allow for
allocation of values prior to publication, the Designated Expert(s) the allocation of values prior to publication, the Designated
may approve registration once they are satisfied that such a Expert(s) may approve registration once they are satisfied that such
specification will be published. a specification will be published.
Registration requests must be sent to the [TBD]@ietf.org mailing list Registration requests must be sent to the [TBD]@ietf.org mailing list
for review and comment, with an appropriate subject (e.g., "Request for review and comment, with an appropriate subject (e.g., "Request
for access token type: example"). [[ Note to the RFC Editor: The name for access token type: example"). [[ Note to the RFC Editor: The name
of the mailing list should be determined in consultation with the of the mailing list should be determined in consultation with the
IESG and IANA. Suggested name: jose-reg-review. ]] IESG and IANA. Suggested name: jose-reg-review. ]]
Within the review period, the Designated Expert(s) will either Within the review period, the Designated Expert(s) will either
approve or deny the registration request, communicating this decision approve or deny the registration request, communicating this decision
to the review list and IANA. Denials should include an explanation to the review list and IANA. Denials should include an explanation
skipping to change at page 48, line 21 skipping to change at page 48, line 21
o Specification Document(s): Section 6.2.1.1 of [[ this document ]] o Specification Document(s): Section 6.2.1.1 of [[ this document ]]
o Curve Name: "P-521" o Curve Name: "P-521"
o Curve Description: P-521 curve o Curve Description: P-521 curve
o JOSE Implementation Requirements: Optional o JOSE Implementation Requirements: Optional
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 6.2.1.1 of [[ this document ]] o Specification Document(s): Section 6.2.1.1 of [[ this document ]]
8. Security Considerations 8. Security Considerations
All of the security issues faced by any cryptographic application All of the security issues that are pertinent to any cryptographic
must be faced by a JWS/JWE/JWK agent. Among these issues are application must be addressed by JWS/JWE/JWK agents. Among these
protecting the user's asymmetric private and symmetric secret keys, issues are protecting the user's asymmetric private and symmetric
preventing various attacks, and helping avoid mistakes such as secret keys, preventing various attacks, and helping avoid mistakes
inadvertently encrypting a message to the wrong recipient. The such as inadvertently encrypting a message to the wrong recipient.
entire list of security considerations is beyond the scope of this The entire list of security considerations is beyond the scope of
document, but some significant considerations are listed here. this document, but some significant considerations are listed here.
The security considerations in [AES], [DSS], [JWE], [JWK], [JWS], The security considerations in [AES], [DSS], [JWE], [JWK], [JWS],
[NIST.800-38A], [NIST.800-38D], [NIST.800-56A], [RFC2104], [RFC3394], [NIST.800-38A], [NIST.800-38D], [NIST.800-56A], [RFC2104], [RFC3394],
[RFC3447], [RFC5116], [RFC6090], and [SHS] apply to this [RFC3447], [RFC5116], [RFC6090], and [SHS] apply to this
specification. specification.
8.1. Algorithms and Key Sizes will be Deprecated 8.1. Algorithms and Key Sizes will be Deprecated
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
skipping to change at page 49, line 14 skipping to change at page 49, line 14
8.3. RSAES-PKCS1-v1_5 Security Considerations 8.3. RSAES-PKCS1-v1_5 Security Considerations
While Section 8 of RFC 3447 [RFC3447] explicitly calls for people not While Section 8 of RFC 3447 [RFC3447] explicitly calls for people not
to adopt RSASSA-PKCS-v1_5 for new applications and instead requests to adopt RSASSA-PKCS-v1_5 for new applications and instead requests
that people transition to RSASSA-PSS, this specification does include that people transition to RSASSA-PSS, this specification does include
RSASSA-PKCS-v1_5, for interoperability reasons, because it commonly RSASSA-PKCS-v1_5, for interoperability reasons, because it commonly
implemented. implemented.
Keys used with RSAES-PKCS1-v1_5 must follow the constraints in Keys used with RSAES-PKCS1-v1_5 must follow the constraints in
Section 7.2 of RFC 3447 [RFC3447]. In particular, keys with a low Section 7.2 of RFC 3447. In particular, keys with a low public key
public key exponent value must not be used. exponent value must not be used.
8.4. AES GCM Security Considerations 8.4. AES GCM Security Considerations
Keys used with AES GCM must follow the constraints in Section 8.3 of Keys used with AES GCM must follow the constraints in Section 8.3 of
[NIST.800-38D], which states: "The total number of invocations of the [NIST.800-38D], which states: "The total number of invocations of the
authenticated encryption function shall not exceed 2^32, including authenticated encryption function shall not exceed 2^32, including
all IV lengths and all instances of the authenticated encryption all IV lengths and all instances of the authenticated encryption
function with the given key". In accordance with this rule, AES GCM function with the given key". In accordance with this rule, AES GCM
MUST NOT be used with the same key value more than 2^32 times. MUST NOT be used with the same key value more than 2^32 times.
skipping to change at page 50, line 38 skipping to change at page 50, line 38
cryptographic resource management system to prevent such attacks. cryptographic resource management system to prevent such attacks.
8.7. Reusing Key Material when Encrypting Keys 8.7. Reusing Key Material when Encrypting Keys
It is NOT RECOMMENDED to reuse the same key material (Key Encryption It is NOT RECOMMENDED to reuse the same key material (Key Encryption
Key, Content Encryption Key, Initialization Vector, etc.) to encrypt Key, Content Encryption Key, Initialization Vector, etc.) to encrypt
multiple JWK or JWK Set objects, or to encrypt the same JWK or JWK multiple JWK or JWK Set objects, or to encrypt the same JWK or JWK
Set object multiple times. One suggestion for preventing re-use is Set object multiple times. One suggestion for preventing re-use is
to always generate a new set key material for each encryption to always generate a new set key material for each encryption
operation, based on the considerations noted in this document as well operation, based on the considerations noted in this document as well
as from [RFC4086]. as from RFC 4086 [RFC4086].
8.8. Password Considerations 8.8. Password Considerations
Passwords are vulnerable to a number of attacks. To help mitigate Passwords are vulnerable to a number of attacks. To help mitigate
some of these limitations, this document applies principles from some of these limitations, this document applies principles from RFC
[RFC2898] to derive cryptographic keys from user-supplied passwords. 2898 [RFC2898] to derive cryptographic keys from user-supplied
passwords.
However, the strength of the password still has a significant impact. However, the strength of the password still has a significant impact.
A high-entropy password has greater resistance to dictionary attacks. A high-entropy password has greater resistance to dictionary attacks.
[NIST-800-63-1] contains guidelines for estimating password entropy, [NIST-800-63-1] contains guidelines for estimating password entropy,
which can help applications and users generate stronger passwords. which can help applications and users generate stronger passwords.
An ideal password is one that is as large as (or larger than) the An ideal password is one that is as large as (or larger than) the
derived key length. However, passwords larger than a certain derived key length. However, passwords larger than a certain
algorithm-specific size are first hashed, which reduces an attacker's algorithm-specific size are first hashed, which reduces an attacker's
effective search space to the length of the hash algorithm. It is effective search space to the length of the hash algorithm. It is
skipping to change at page 52, line 23 skipping to change at page 52, line 27
[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
Signature Standard (DSS)", FIPS PUB 186-4, July 2013. Signature Standard (DSS)", FIPS PUB 186-4, July 2013.
[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", [JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
draft-ietf-jose-json-web-encryption (work in progress), draft-ietf-jose-json-web-encryption (work in progress),
June 2014. July 2014.
[JWK] Jones, M., "JSON Web Key (JWK)", [JWK] Jones, M., "JSON Web Key (JWK)",
draft-ietf-jose-json-web-key (work in progress), draft-ietf-jose-json-web-key (work in progress),
June 2014. July 2014.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", draft-ietf-jose-json-web-signature (work Signature (JWS)", draft-ietf-jose-json-web-signature (work
in progress), June 2014. in progress), July 2014.
[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,
skipping to change at page 53, line 16 skipping to change at page 53, line 19
[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.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, September 2000. Specification Version 2.0", RFC 2898, September 2000.
[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
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
[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.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
skipping to change at page 54, line 43 skipping to change at page 54, line 50
"Electronic Authentication Guideline", NIST 800-63-1, "Electronic Authentication Guideline", NIST 800-63-1,
December 2011. December 2011.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
RFC 2631, June 1999. RFC 2631, June 1999.
[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.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, January 2008. 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.
skipping to change at page 64, line 15 skipping to change at page 64, line 15
[I-D.miller-jose-jwe-protected-jwk], which the password-based [I-D.miller-jose-jwe-protected-jwk], which the password-based
encryption content of this draft is based upon. encryption content of this draft is based upon.
This specification is the work of the JOSE Working Group, which This specification is the work of the JOSE Working Group, which
includes dozens of active and dedicated participants. In particular, includes dozens of active and dedicated participants. In particular,
the following individuals contributed ideas, feedback, and wording the following individuals contributed ideas, feedback, and wording
that influenced this specification: that influenced this specification:
Dirk Balfanz, Richard Barnes, John Bradley, Brian Campbell, Breno de Dirk Balfanz, Richard Barnes, John Bradley, Brian Campbell, Breno de
Medeiros, Vladimir Dzhuvinov, Yaron Y. Goland, Dick Hardt, Joe Medeiros, Vladimir Dzhuvinov, Yaron Y. Goland, Dick Hardt, Joe
Hildebrand, Jeff Hodges, Edmund Jay, James Manger, Matt Miller, Tony Hildebrand, Jeff Hodges, Edmund Jay, James Manger, Matt Miller,
Nadalin, Axel Nennker, John Panzer, Emmanuel Raviart, Eric Rescorla, Kathleen Moriarty, Tony Nadalin, Axel Nennker, John Panzer, Emmanuel
Nat Sakimura, Jim Schaad, Hannes Tschofenig, and Sean Turner. Raviart, Eric Rescorla, Nat Sakimura, Jim Schaad, Hannes Tschofenig,
and Sean Turner.
Jim Schaad and Karen O'Donoghue chaired the JOSE working group and Jim Schaad and Karen O'Donoghue chaired the JOSE working group and
Sean Turner, Stephen Farrell, and Kathleen Moriarty served as Sean Turner, Stephen Farrell, and Kathleen Moriarty served as
Security area directors during the creation of this specification. Security area directors during the creation of this specification.
Appendix E. Document History Appendix E. 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 ]]
-30
o Cleaned up the reference syntax in a few places.
o Applied minor wording changes to the Security Considerations
section.
-29 -29
o Replaced the terms JWS Header, JWE Header, and JWT Header with a o Replaced the terms JWS Header, JWE Header, and JWT Header with a
single JOSE Header term defined in the JWS specification. This single JOSE Header term defined in the JWS specification. This
also enabled a single Header Parameter definition to be used and also enabled a single Header Parameter definition to be used and
reduced other areas of duplication between specifications. reduced other areas of duplication between specifications.
-28 -28
o Specified the use of PKCS #7 padding with AES CBC, rather than o Specified the use of PKCS #7 padding with AES CBC, rather than
 End of changes. 20 change blocks. 
40 lines changed or deleted 49 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/