draft-ietf-jose-json-web-algorithms-35.txt   draft-ietf-jose-json-web-algorithms-36.txt 
JOSE Working Group M. Jones JOSE Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track October 17, 2014 Intended status: Standards Track October 24, 2014
Expires: April 20, 2015 Expires: April 27, 2015
JSON Web Algorithms (JWA) JSON Web Algorithms (JWA)
draft-ietf-jose-json-web-algorithms-35 draft-ietf-jose-json-web-algorithms-36
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 April 20, 2015. This Internet-Draft will expire on April 27, 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 2, line 22 skipping to change at page 2, line 22
3.2. HMAC with SHA-2 Functions . . . . . . . . . . . . . . . . 7 3.2. HMAC with SHA-2 Functions . . . . . . . . . . . . . . . . 7
3.3. Digital Signature with RSASSA-PKCS1-V1_5 . . . . . . . . . 8 3.3. Digital Signature with RSASSA-PKCS1-V1_5 . . . . . . . . . 8
3.4. Digital Signature with ECDSA . . . . . . . . . . . . . . . 9 3.4. Digital Signature with ECDSA . . . . . . . . . . . . . . . 9
3.5. Digital Signature with RSASSA-PSS . . . . . . . . . . . . 11 3.5. Digital Signature with RSASSA-PSS . . . . . . . . . . . . 11
3.6. Using the Algorithm "none" . . . . . . . . . . . . . . . . 12 3.6. Using the Algorithm "none" . . . . . . . . . . . . . . . . 12
4. Cryptographic Algorithms for Key Management . . . . . . . . . 12 4. Cryptographic Algorithms for Key Management . . . . . . . . . 12
4.1. "alg" (Algorithm) Header Parameter Values for JWE . . . . 12 4.1. "alg" (Algorithm) Header Parameter Values for JWE . . . . 12
4.2. Key Encryption with RSAES-PKCS1-V1_5 . . . . . . . . . . . 14 4.2. Key Encryption with RSAES-PKCS1-V1_5 . . . . . . . . . . . 14
4.3. Key Encryption with RSAES OAEP . . . . . . . . . . . . . . 14 4.3. Key Encryption with RSAES OAEP . . . . . . . . . . . . . . 14
4.4. Key Wrapping with AES Key Wrap . . . . . . . . . . . . . . 15 4.4. Key Wrapping with AES Key Wrap . . . . . . . . . . . . . . 15
4.5. Direct Encryption with a Shared Symmetric Key . . . . . . 15 4.5. Direct Encryption with a Shared Symmetric Key . . . . . . 16
4.6. Key Agreement with Elliptic Curve Diffie-Hellman 4.6. Key Agreement with Elliptic Curve Diffie-Hellman
Ephemeral Static (ECDH-ES) . . . . . . . . . . . . . . . . 15 Ephemeral Static (ECDH-ES) . . . . . . . . . . . . . . . . 16
4.6.1. Header Parameters Used for ECDH Key Agreement . . . . 16 4.6.1. Header Parameters Used for ECDH Key Agreement . . . . 17
4.6.1.1. "epk" (Ephemeral Public Key) Header Parameter . . 16 4.6.1.1. "epk" (Ephemeral Public Key) Header Parameter . . 17
4.6.1.2. "apu" (Agreement PartyUInfo) Header Parameter . . 17 4.6.1.2. "apu" (Agreement PartyUInfo) Header Parameter . . 17
4.6.1.3. "apv" (Agreement PartyVInfo) Header Parameter . . 17 4.6.1.3. "apv" (Agreement PartyVInfo) Header Parameter . . 17
4.6.2. Key Derivation for ECDH Key Agreement . . . . . . . . 17 4.6.2. Key Derivation for ECDH Key Agreement . . . . . . . . 18
4.7. Key Encryption with AES GCM . . . . . . . . . . . . . . . 19 4.7. Key Encryption with AES GCM . . . . . . . . . . . . . . . 19
4.7.1. Header Parameters Used for AES GCM Key Encryption . . 19 4.7.1. Header Parameters Used for AES GCM Key Encryption . . 20
4.7.1.1. "iv" (Initialization Vector) Header Parameter . . 19 4.7.1.1. "iv" (Initialization Vector) Header Parameter . . 20
4.7.1.2. "tag" (Authentication Tag) Header Parameter . . . 20 4.7.1.2. "tag" (Authentication Tag) Header Parameter . . . 20
4.8. Key Encryption with PBES2 . . . . . . . . . . . . . . . . 20 4.8. Key Encryption with PBES2 . . . . . . . . . . . . . . . . 20
4.8.1. Header Parameters Used for PBES2 Key Encryption . . . 21 4.8.1. Header Parameters Used for PBES2 Key Encryption . . . 21
4.8.1.1. "p2s" (PBES2 salt input) Parameter . . . . . . . . 21 4.8.1.1. "p2s" (PBES2 salt input) Parameter . . . . . . . . 21
4.8.1.2. "p2c" (PBES2 count) Parameter . . . . . . . . . . 21 4.8.1.2. "p2c" (PBES2 count) Parameter . . . . . . . . . . 21
5. Cryptographic Algorithms for Content Encryption . . . . . . . 21 5. Cryptographic Algorithms for Content Encryption . . . . . . . 22
5.1. "enc" (Encryption Algorithm) Header Parameter Values 5.1. "enc" (Encryption Algorithm) Header Parameter Values
for JWE . . . . . . . . . . . . . . . . . . . . . . . . . 21 for JWE . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2. AES_CBC_HMAC_SHA2 Algorithms . . . . . . . . . . . . . . . 22 5.2. AES_CBC_HMAC_SHA2 Algorithms . . . . . . . . . . . . . . . 23
5.2.1. Conventions Used in Defining AES_CBC_HMAC_SHA2 . . . . 23 5.2.1. Conventions Used in Defining AES_CBC_HMAC_SHA2 . . . . 23
5.2.2. Generic AES_CBC_HMAC_SHA2 Algorithm . . . . . . . . . 23 5.2.2. Generic AES_CBC_HMAC_SHA2 Algorithm . . . . . . . . . 23
5.2.2.1. AES_CBC_HMAC_SHA2 Encryption . . . . . . . . . . . 23 5.2.2.1. AES_CBC_HMAC_SHA2 Encryption . . . . . . . . . . . 23
5.2.2.2. AES_CBC_HMAC_SHA2 Decryption . . . . . . . . . . . 24 5.2.2.2. AES_CBC_HMAC_SHA2 Decryption . . . . . . . . . . . 25
5.2.3. AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . . 25 5.2.3. AES_128_CBC_HMAC_SHA_256 . . . . . . . . . . . . . . . 25
5.2.4. AES_192_CBC_HMAC_SHA_384 . . . . . . . . . . . . . . . 26 5.2.4. AES_192_CBC_HMAC_SHA_384 . . . . . . . . . . . . . . . 26
5.2.5. AES_256_CBC_HMAC_SHA_512 . . . . . . . . . . . . . . . 26 5.2.5. AES_256_CBC_HMAC_SHA_512 . . . . . . . . . . . . . . . 26
5.2.6. Content Encryption with AES_CBC_HMAC_SHA2 . . . . . . 26 5.2.6. Content Encryption with AES_CBC_HMAC_SHA2 . . . . . . 27
5.3. Content Encryption with AES GCM . . . . . . . . . . . . . 27 5.3. Content Encryption with AES GCM . . . . . . . . . . . . . 27
6. Cryptographic Algorithms for Keys . . . . . . . . . . . . . . 27 6. Cryptographic Algorithms for Keys . . . . . . . . . . . . . . 28
6.1. "kty" (Key Type) Parameter Values . . . . . . . . . . . . 28 6.1. "kty" (Key Type) Parameter Values . . . . . . . . . . . . 28
6.2. Parameters for Elliptic Curve Keys . . . . . . . . . . . . 28 6.2. Parameters for Elliptic Curve Keys . . . . . . . . . . . . 28
6.2.1. Parameters for Elliptic Curve Public Keys . . . . . . 28 6.2.1. Parameters for Elliptic Curve Public Keys . . . . . . 28
6.2.1.1. "crv" (Curve) Parameter . . . . . . . . . . . . . 28 6.2.1.1. "crv" (Curve) Parameter . . . . . . . . . . . . . 29
6.2.1.2. "x" (X Coordinate) Parameter . . . . . . . . . . . 29 6.2.1.2. "x" (X Coordinate) Parameter . . . . . . . . . . . 29
6.2.1.3. "y" (Y Coordinate) Parameter . . . . . . . . . . . 29 6.2.1.3. "y" (Y Coordinate) Parameter . . . . . . . . . . . 29
6.2.2. Parameters for Elliptic Curve Private Keys . . . . . . 29 6.2.2. Parameters for Elliptic Curve Private Keys . . . . . . 30
6.2.2.1. "d" (ECC Private Key) Parameter . . . . . . . . . 29 6.2.2.1. "d" (ECC Private Key) Parameter . . . . . . . . . 30
6.3. Parameters for RSA Keys . . . . . . . . . . . . . . . . . 30 6.3. Parameters for RSA Keys . . . . . . . . . . . . . . . . . 30
6.3.1. Parameters for RSA Public Keys . . . . . . . . . . . . 30 6.3.1. Parameters for RSA Public Keys . . . . . . . . . . . . 30
6.3.1.1. "n" (Modulus) Parameter . . . . . . . . . . . . . 30 6.3.1.1. "n" (Modulus) Parameter . . . . . . . . . . . . . 30
6.3.1.2. "e" (Exponent) Parameter . . . . . . . . . . . . . 30 6.3.1.2. "e" (Exponent) Parameter . . . . . . . . . . . . . 30
6.3.2. Parameters for RSA Private Keys . . . . . . . . . . . 30 6.3.2. Parameters for RSA Private Keys . . . . . . . . . . . 31
6.3.2.1. "d" (Private Exponent) Parameter . . . . . . . . . 30 6.3.2.1. "d" (Private Exponent) Parameter . . . . . . . . . 31
6.3.2.2. "p" (First Prime Factor) Parameter . . . . . . . . 31 6.3.2.2. "p" (First Prime Factor) Parameter . . . . . . . . 31
6.3.2.3. "q" (Second Prime Factor) Parameter . . . . . . . 31 6.3.2.3. "q" (Second Prime Factor) Parameter . . . . . . . 31
6.3.2.4. "dp" (First Factor CRT Exponent) Parameter . . . . 31 6.3.2.4. "dp" (First Factor CRT Exponent) Parameter . . . . 31
6.3.2.5. "dq" (Second Factor CRT Exponent) Parameter . . . 31 6.3.2.5. "dq" (Second Factor CRT Exponent) Parameter . . . 31
6.3.2.6. "qi" (First CRT Coefficient) Parameter . . . . . . 31 6.3.2.6. "qi" (First CRT Coefficient) Parameter . . . . . . 31
6.3.2.7. "oth" (Other Primes Info) Parameter . . . . . . . 31 6.3.2.7. "oth" (Other Primes Info) Parameter . . . . . . . 32
6.4. Parameters for Symmetric Keys . . . . . . . . . . . . . . 32 6.4. Parameters for Symmetric Keys . . . . . . . . . . . . . . 32
6.4.1. "k" (Key Value) Parameter . . . . . . . . . . . . . . 32 6.4.1. "k" (Key Value) Parameter . . . . . . . . . . . . . . 32
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
7.1. JSON Web Signature and Encryption Algorithms Registry . . 33 7.1. JSON Web Signature and Encryption Algorithms Registry . . 34
7.1.1. Registration Template . . . . . . . . . . . . . . . . 34 7.1.1. Registration Template . . . . . . . . . . . . . . . . 34
7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 35 7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 35
7.2. Header Parameter Names Registration . . . . . . . . . . . 41 7.2. Header Parameter Names Registration . . . . . . . . . . . 41
7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 41 7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 41
7.3. JSON Web Encryption Compression Algorithms Registry . . . 42 7.3. JSON Web Encryption Compression Algorithms Registry . . . 42
7.3.1. Registration Template . . . . . . . . . . . . . . . . 42 7.3.1. Registration Template . . . . . . . . . . . . . . . . 42
7.3.2. Initial Registry Contents . . . . . . . . . . . . . . 43 7.3.2. Initial Registry Contents . . . . . . . . . . . . . . 43
7.4. JSON Web Key Types Registry . . . . . . . . . . . . . . . 43 7.4. JSON Web Key Types Registry . . . . . . . . . . . . . . . 43
7.4.1. Registration Template . . . . . . . . . . . . . . . . 43 7.4.1. Registration Template . . . . . . . . . . . . . . . . 44
7.4.2. Initial Registry Contents . . . . . . . . . . . . . . 44 7.4.2. Initial Registry Contents . . . . . . . . . . . . . . 44
7.5. JSON Web Key Parameters Registration . . . . . . . . . . . 44 7.5. JSON Web Key Parameters Registration . . . . . . . . . . . 45
7.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 44 7.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 45
7.6. JSON Web Key Elliptic Curve Registry . . . . . . . . . . . 47 7.6. JSON Web Key Elliptic Curve Registry . . . . . . . . . . . 47
7.6.1. Registration Template . . . . . . . . . . . . . . . . 47 7.6.1. Registration Template . . . . . . . . . . . . . . . . 47
7.6.2. Initial Registry Contents . . . . . . . . . . . . . . 48 7.6.2. Initial Registry Contents . . . . . . . . . . . . . . 48
8. Security Considerations . . . . . . . . . . . . . . . . . . . 48 8. Security Considerations . . . . . . . . . . . . . . . . . . . 49
8.1. Cryptographic Agility . . . . . . . . . . . . . . . . . . 48 8.1. Cryptographic Agility . . . . . . . . . . . . . . . . . . 49
8.2. Key Lifetimes . . . . . . . . . . . . . . . . . . . . . . 49 8.2. Key Lifetimes . . . . . . . . . . . . . . . . . . . . . . 49
8.3. RSAES-PKCS1-v1_5 Security Considerations . . . . . . . . . 49 8.3. RSAES-PKCS1-v1_5 Security Considerations . . . . . . . . . 49
8.4. AES GCM Security Considerations . . . . . . . . . . . . . 49 8.4. AES GCM Security Considerations . . . . . . . . . . . . . 49
8.5. Unsecured JWS Security Considerations . . . . . . . . . . 49 8.5. Unsecured JWS Security Considerations . . . . . . . . . . 50
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 . . . . . . . . 51
8.8. Password Considerations . . . . . . . . . . . . . . . . . 51 8.8. Password Considerations . . . . . . . . . . . . . . . . . 51
8.9. Key Entropy and Random Values . . . . . . . . . . . . . . 51 8.9. Key Entropy and Random Values . . . . . . . . . . . . . . 52
8.10. Differences between Digital Signatures and MACs . . . . . 51 8.10. Differences between Digital Signatures and MACs . . . . . 52
8.11. Using Matching Algorithm Strengths . . . . . . . . . . . . 51 8.11. Using Matching Algorithm Strengths . . . . . . . . . . . . 52
8.12. Adaptive Chosen-Ciphertext Attacks . . . . . . . . . . . . 52 8.12. Adaptive Chosen-Ciphertext Attacks . . . . . . . . . . . . 52
8.13. Timing Attacks . . . . . . . . . . . . . . . . . . . . . . 52 8.13. Timing Attacks . . . . . . . . . . . . . . . . . . . . . . 52
8.14. RSA Private Key Representations and Blinding . . . . . . . 52 8.14. RSA Private Key Representations and Blinding . . . . . . . 52
9. Internationalization Considerations . . . . . . . . . . . . . 52 9. Internationalization Considerations . . . . . . . . . . . . . 52
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
10.1. Normative References . . . . . . . . . . . . . . . . . . . 52 10.1. Normative References . . . . . . . . . . . . . . . . . . . 52
10.2. Informative References . . . . . . . . . . . . . . . . . . 54 10.2. Informative References . . . . . . . . . . . . . . . . . . 54
Appendix A. Algorithm Identifier Cross-Reference . . . . . . . . 56 Appendix A. Algorithm Identifier Cross-Reference . . . . . . . . 56
A.1. Digital Signature/MAC Algorithm Identifier A.1. Digital Signature/MAC Algorithm Identifier
Cross-Reference . . . . . . . . . . . . . . . . . . . . . 56 Cross-Reference . . . . . . . . . . . . . . . . . . . . . 57
A.2. Key Management Algorithm Identifier Cross-Reference . . . 57 A.2. Key Management Algorithm Identifier Cross-Reference . . . 57
A.3. Content Encryption Algorithm Identifier Cross-Reference . 58 A.3. Content Encryption Algorithm Identifier Cross-Reference . 58
Appendix B. Test Cases for AES_CBC_HMAC_SHA2 Algorithms . . . . . 59 Appendix B. Test Cases for AES_CBC_HMAC_SHA2 Algorithms . . . . . 59
B.1. Test Cases for AES_128_CBC_HMAC_SHA_256 . . . . . . . . . 60 B.1. Test Cases for AES_128_CBC_HMAC_SHA_256 . . . . . . . . . 60
B.2. Test Cases for AES_192_CBC_HMAC_SHA_384 . . . . . . . . . 61 B.2. Test Cases for AES_192_CBC_HMAC_SHA_384 . . . . . . . . . 61
B.3. Test Cases for AES_256_CBC_HMAC_SHA_512 . . . . . . . . . 62 B.3. Test Cases for AES_256_CBC_HMAC_SHA_512 . . . . . . . . . 62
Appendix C. Example ECDH-ES Key Agreement Computation . . . . . . 63 Appendix C. Example ECDH-ES Key Agreement Computation . . . . . . 63
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 65 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 65
Appendix E. Document History . . . . . . . . . . . . . . . . . . 66 Appendix E. Document History . . . . . . . . . . . . . . . . . . 66
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 76
skipping to change at page 12, line 12 skipping to change at page 12, line 12
RSASSA-PSS SHA-256 -- just using the alternative hash algorithm in RSASSA-PSS SHA-256 -- just using the alternative hash algorithm in
both roles. both roles.
3.6. Using the Algorithm "none" 3.6. Using the Algorithm "none"
JWSs MAY also be created that do not provide integrity protection. JWSs MAY also be created that do not provide integrity protection.
Such a JWS is called an Unsecured JWS. An Unsecured JWS MUST use the Such a JWS is called an Unsecured JWS. An Unsecured JWS MUST use the
"alg" value "none", and is formatted identically to other JWSs, but "alg" value "none", and is formatted identically to other JWSs, but
MUST use the empty octet sequence as its JWS Signature value. MUST use the empty octet sequence as its JWS Signature value.
Recipients MUST verify that the JWS Signature value is the empty Recipients MUST verify that the JWS Signature value is the empty
octet sequence. See Section 8.5 for security considerations octet sequence.
associated with using this algorithm.
Implementations that support Unsecured JWS objects MUST NOT accept
such objects as valid unless the application specifies that it is
acceptable for a specific object to not be integrity protected.
Implementations MUST NOT accept Unsecured JWS objects by default. In
order to mitigate downgrade attacks, applications MUST NOT signal
acceptance of Unsecured JWS objects at a global level, and SHOULD
signal acceptance on a per-object basis. See Section 8.5 for
security considerations associated with using this algorithm.
4. Cryptographic Algorithms for Key Management 4. Cryptographic Algorithms for Key Management
JWE uses cryptographic algorithms to encrypt or determine the Content JWE uses cryptographic algorithms to encrypt or determine the Content
Encryption Key (CEK). Encryption Key (CEK).
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.
skipping to change at page 30, line 8 skipping to change at page 30, line 22
The "d" (ECC private key) member contains the Elliptic Curve private The "d" (ECC private key) member contains the Elliptic Curve private
key value. It is represented as the base64url encoding of the octet key value. It is represented as the base64url encoding of the octet
string representation of the private key value, as defined in Section string representation of the private key value, as defined in Section
2.3.7 of SEC1 [SEC1]. The length of this octet string MUST be 2.3.7 of SEC1 [SEC1]. The length of this octet string MUST be
ceiling(log-base-2(n)/8) octets (where n is the order of the curve). ceiling(log-base-2(n)/8) octets (where n is the order of the curve).
6.3. Parameters for RSA Keys 6.3. Parameters for RSA Keys
JWKs can represent RSA [RFC3447] keys. In this case, the "kty" JWKs can represent RSA [RFC3447] keys. In this case, the "kty"
member value is "RSA". member value is "RSA". The semantics of the parameters defined below
are the same as those defined in Sections 3.1 and 3.2 of RFC 3447.
6.3.1. Parameters for RSA Public Keys 6.3.1. Parameters for RSA Public Keys
The following members MUST be present for RSA public keys. The following members MUST be present for RSA public keys.
6.3.1.1. "n" (Modulus) Parameter 6.3.1.1. "n" (Modulus) Parameter
The "n" (modulus) member contains the modulus value for the RSA The "n" (modulus) member contains the modulus value for the RSA
public key. It is represented as a Base64urlUInt encoded value. public key. It is represented as a Base64urlUInt encoded value.
skipping to change at page 32, line 38 skipping to change at page 33, line 11
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 on a Specification Required [RFC5226] basis Values are registered on a Specification Required [RFC5226] basis
after a three-week review period on the [TBD]@ietf.org mailing list, after a three-week review period on the jose-reg-review@ietf.org
on the advice of one or more Designated Experts. However, to allow mailing list, on the advice of one or more Designated Experts.
for the allocation of values prior to publication, the Designated However, to allow for the allocation of values prior to publication,
Expert(s) may approve registration once they are satisfied that such the Designated Expert(s) may approve registration once they are
a specification will be published. satisfied that such a specification will be published.
Registration requests must be sent to the [TBD]@ietf.org mailing list Registration requests must be sent to the jose-reg-review@ietf.org
for review and comment, with an appropriate subject (e.g., "Request mailing list for review and comment, with an appropriate subject
for access token type: example"). [[ Note to the RFC Editor: The name (e.g., "Request for access token type: example").
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 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
and, if applicable, suggestions as to how to make the request and, if applicable, suggestions as to how to make the request
successful. Registration requests that are undetermined for a period successful. Registration requests that are undetermined for a period
longer than 21 days can be brought to the IESG's attention (using the longer than 21 days can be brought to the IESG's attention (using the
iesg@ietf.org mailing list) for resolution. iesg@ietf.org mailing list) for resolution.
Criteria that should be applied by the Designated Expert(s) includes Criteria that should be applied by the Designated Expert(s) includes
skipping to change at page 49, line 51 skipping to change at page 50, line 24
This security consideration does not apply to the composite AES-CBC This security consideration does not apply to the composite AES-CBC
HMAC SHA-2 or AES Key Wrap algorithms. HMAC SHA-2 or AES Key Wrap algorithms.
8.5. Unsecured JWS Security Considerations 8.5. Unsecured JWS Security Considerations
Unsecured JWSs (JWSs that use the "alg" value "none") provide no Unsecured JWSs (JWSs that use the "alg" value "none") provide no
integrity protection. Thus, they must only be used in contexts in integrity protection. Thus, they must only be used in contexts in
which the payload is secured by means other than a digital signature which the payload is secured by means other than a digital signature
or MAC value, or need not be secured. or MAC value, or need not be secured.
Implementations that support Unsecured JWS objects MUST NOT accept An example means of preventing accepting Unsecured JWS objects by
such objects as valid unless the application specifies that it is default is for the "verify" method of a hypothetical JWS software
acceptable for a specific object to not be integrity-protected. library to have a Boolean "acceptUnsecured" parameter that indicates
Implementations MUST NOT accept Unsecured JWS objects by default. "none" is an acceptable "alg" value. As another example, the
For example, the "verify" method of a hypothetical JWS software "verify" method might take a list of algorithms that are acceptable
library might have a Boolean "acceptUnsigned" parameter that to the application as a parameter and would reject Unsecured JWS
indicates "none" is an acceptable "alg" value. As another example, values if "none" is not in that list.
the "verify" method might take a list of algorithms that are
acceptable to the application as a parameter and would reject
Unsecured JWS values if "none" is not in that list.
In order to mitigate downgrade attacks, applications MUST NOT signal The following example illustrates the reasons for not accepting
acceptance of Unsecured JWS objects at a global level, and SHOULD Unsecured JWS objects at a global level. Suppose an application
signal acceptance on a per-object basis. For example, suppose an accepts JWS objects over two channels, (1) HTTP and (2) HTTPS with
application accepts JWS objects over two channels, (1) HTTP and (2) client authentication. It requires a JWS signature on objects
HTTPS with client authentication. It requires a JWS signature on received over HTTP, but accepts Unsecured JWS objects over HTTPS. If
objects received over HTTP, but accepts Unsecured JWS objects over the application were to globally indicate that "none" is acceptable,
HTTPS. If the application were to globally indicate that "none" is then an attacker could provide it with an Unsecured JWS object over
acceptable, then an attacker could provide it with an unsigned object HTTP and still have that object successfully validate. Instead, the
over HTTP and still have that object successfully validate. Instead, application needs to indicate acceptance of "none" for each object
the application needs to indicate acceptance of "none" for each received over HTTPS (e.g., by setting "acceptUnsecured" to "true" for
object received over HTTPS (e.g., by setting "acceptUnsigned" to the first hypothetical JWS software library above), but not for each
"true" for the first hypothetical JWS software library above), but object received over HTTP.
not for each object received over HTTP.
8.6. Denial of Service Attacks 8.6. Denial of Service Attacks
Receiving agents that validate signatures and sending agents that Receiving agents that validate signatures and sending agents that
encrypt messages need to be cautious of cryptographic processing encrypt messages need to be cautious of cryptographic processing
usage when validating signatures and encrypting messages using keys usage when validating signatures and encrypting messages using keys
larger than those mandated in this specification. An attacker could larger than those mandated in this specification. An attacker could
supply content using keys that would result in excessive supply content using keys that would result in excessive
cryptographic processing, for example, keys larger than those cryptographic processing, for example, keys larger than those
mandated in this specification. Implementations should set and mandated in this specification. Implementations should set and
skipping to change at page 54, line 39 skipping to change at page 55, line 6
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
10.2. Informative References 10.2. Informative References
[CanvasApp] [CanvasApp]
Facebook, "Canvas Applications", 2010. Facebook, "Canvas Applications", 2010.
[I-D.ietf-precis-saslprepbis] [I-D.ietf-precis-saslprepbis]
Saint-Andre, P. and A. Melnikov, "Preparation and Saint-Andre, P. and A. Melnikov, "Preparation,
Comparison of Internationalized Strings Representing Enforcement, and Comparison of Internationalized Strings
Usernames and Passwords", draft-ietf-precis-saslprepbis-08 Representing Usernames and Passwords",
(work in progress), October 2014. draft-ietf-precis-saslprepbis-09 (work in progress),
October 2014.
[I-D.mcgrew-aead-aes-cbc-hmac-sha2] [I-D.mcgrew-aead-aes-cbc-hmac-sha2]
McGrew, D., Foley, J., and K. Paterson, "Authenticated McGrew, D., Foley, J., and K. Paterson, "Authenticated
Encryption with AES-CBC and HMAC-SHA", Encryption with AES-CBC and HMAC-SHA",
draft-mcgrew-aead-aes-cbc-hmac-sha2-05 (work in progress), draft-mcgrew-aead-aes-cbc-hmac-sha2-05 (work in progress),
July 2014. July 2014.
[I-D.miller-jose-jwe-protected-jwk] [I-D.miller-jose-jwe-protected-jwk]
Miller, M., "Using JavaScript Object Notation (JSON) Web Miller, M., "Using JavaScript Object Notation (JSON) Web
Encryption (JWE) for Protecting JSON Web Key (JWK) Encryption (JWE) for Protecting JSON Web Key (JWK)
skipping to change at page 66, line 29 skipping to change at page 66, line 29
Jim Schaad, Hannes Tschofenig, and Sean Turner. 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 ]]
-36
o Moved the normative "alg":"none" security considerations text into
the algorithm definition.
o Specified that registration reviews occur on the
jose-reg-review@ietf.org mailing list.
-35 -35
o Addressed AppsDir reviews by Carsten Bormann. o Addressed AppsDir reviews by Carsten Bormann.
o Adjusted some table column widths. o Adjusted some table column widths.
-34 -34
o Addressed IESG review comments by Barry Leiba, Alissa Cooper, Pete o Addressed IESG review comments by Barry Leiba, Alissa Cooper, Pete
Resnick, Stephen Farrell, and Richard Barnes. Resnick, Stephen Farrell, and Richard Barnes.
 End of changes. 32 change blocks. 
76 lines changed or deleted 88 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/