draft-ietf-jose-json-web-algorithms-27.txt   draft-ietf-jose-json-web-algorithms-28.txt 
JOSE Working Group M. Jones JOSE Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track June 10, 2014 Intended status: Standards Track June 20, 2014
Expires: December 12, 2014 Expires: December 22, 2014
JSON Web Algorithms (JWA) JSON Web Algorithms (JWA)
draft-ietf-jose-json-web-algorithms-27 draft-ietf-jose-json-web-algorithms-28
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 12, 2014. This Internet-Draft will expire on December 22, 2014.
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 3, line 47 skipping to change at page 3, line 47
7.5. JSON Web Key Parameters Registration . . . . . . . . . . . 44 7.5. JSON Web Key Parameters Registration . . . . . . . . . . . 44
7.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 44 7.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 44
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 . . . . . . . . . . . . . . . . . . . 48
8.1. Algorithms and Key Sizes will be Deprecated . . . . . . . 49 8.1. Algorithms and Key Sizes will be Deprecated . . . . . . . 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. Plaintext JWS Security Considerations . . . . . . . . . . 50 8.5. Plaintext JWS Security Considerations . . . . . . . . . . 49
8.6. Differences between Digital Signatures and MACs . . . . . 50 8.6. Denial of Service Attacks . . . . . . . . . . . . . . . . 50
8.7. Denial of Service Attacks . . . . . . . . . . . . . . . . 51 8.7. Reusing Key Material when Encrypting Keys . . . . . . . . 50
8.8. Reusing Key Material when Encrypting Keys . . . . . . . . 51 8.8. Password Considerations . . . . . . . . . . . . . . . . . 51
8.9. Password Considerations . . . . . . . . . . . . . . . . . 51 8.9. Key Entropy . . . . . . . . . . . . . . . . . . . . . . . 51
8.10. Adaptive Chosen-Ciphertext Attacks . . . . . . . . . . . . 52 8.10. Differences between Digital Signatures and MACs . . . . . 51
8.11. Timing Attacks . . . . . . . . . . . . . . . . . . . . . . 52 8.11. Using Matching Algorithm Strengths . . . . . . . . . . . . 51
8.12. RSA Private Key Representations and Blinding . . . . . . . 52 8.12. Adaptive Chosen-Ciphertext Attacks . . . . . . . . . . . . 51
8.13. Timing Attacks . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . 55
A.1. Digital Signature/MAC Algorithm Identifier A.1. Digital Signature/MAC Algorithm Identifier
Cross-Reference . . . . . . . . . . . . . . . . . . . . . 56 Cross-Reference . . . . . . . . . . . . . . . . . . . . . 56
A.2. Key Management Algorithm Identifier Cross-Reference . . . 57 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 . . . . . 58 Appendix B. Test Cases for AES_CBC_HMAC_SHA2 Algorithms . . . . . 58
B.1. Test Cases for AES_128_CBC_HMAC_SHA_256 . . . . . . . . . 59 B.1. Test Cases for AES_128_CBC_HMAC_SHA_256 . . . . . . . . . 59
B.2. Test Cases for AES_192_CBC_HMAC_SHA_384 . . . . . . . . . 60 B.2. Test Cases for AES_192_CBC_HMAC_SHA_384 . . . . . . . . . 60
B.3. Test Cases for AES_256_CBC_HMAC_SHA_512 . . . . . . . . . 61 B.3. Test Cases for AES_256_CBC_HMAC_SHA_512 . . . . . . . . . 61
Appendix C. Example ECDH-ES Key Agreement Computation . . . . . . 62 Appendix C. Example ECDH-ES Key Agreement Computation . . . . . . 62
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 64 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 64
Appendix E. Document History . . . . . . . . . . . . . . . . . . 65 Appendix E. Document History . . . . . . . . . . . . . . . . . . 65
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 74
skipping to change at page 22, line 46 skipping to change at page 22, line 46
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 #5 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
skipping to change at page 23, line 20 skipping to change at page 23, line 20
This option is discussed in Appendix B of that specification. This This option is discussed in Appendix B of that specification. This
algorithm family is a generalization of the algorithm family in algorithm family is a generalization of the algorithm family in
[I-D.mcgrew-aead-aes-cbc-hmac-sha2], and can be used to implement [I-D.mcgrew-aead-aes-cbc-hmac-sha2], and can be used to implement
those algorithms. those algorithms.
5.2.1. Conventions Used in Defining AES_CBC_HMAC_SHA2 5.2.1. Conventions Used in Defining AES_CBC_HMAC_SHA2
We use the following notational conventions. We use the following notational conventions.
CBC-PKCS5-ENC(X, P) denotes the AES CBC encryption of P using PKCS CBC-PKCS5-ENC(X, P) denotes the AES CBC encryption of P using PKCS
#5 padding using the cipher with the key X. #7 padding using the cipher with the key X.
MAC(Y, M) denotes the application of the Message Authentication MAC(Y, M) denotes the application of the Message Authentication
Code (MAC) to the message M, using the key Y. Code (MAC) to the message M, using the key Y.
5.2.2. Generic AES_CBC_HMAC_SHA2 Algorithm 5.2.2. Generic AES_CBC_HMAC_SHA2 Algorithm
This section defines AES_CBC_HMAC_SHA2 in a manner that is This section defines AES_CBC_HMAC_SHA2 in a manner that is
independent of the AES CBC key size or hash function to be used. independent of the AES CBC key size or hash function to be used.
Section 5.2.2.1 and Section 5.2.2.2 define the generic encryption and Section 5.2.2.1 and Section 5.2.2.2 define the generic encryption and
decryption algorithms. Section 5.2.3 and Section 5.2.5 define decryption algorithms. Section 5.2.3 and Section 5.2.5 define
skipping to change at page 24, line 22 skipping to change at page 24, line 22
octets in the input key K is the sum of MAC_KEY_LEN and octets in the input key K is the sum of MAC_KEY_LEN and
ENC_KEY_LEN. When generating the secondary keys from K, MAC_KEY ENC_KEY_LEN. When generating the secondary keys from K, MAC_KEY
and ENC_KEY MUST NOT overlap. Note that the MAC key comes before and ENC_KEY MUST NOT overlap. Note that the MAC key comes before
the encryption key in the input key K; this is in the opposite the encryption key in the input key K; this is in the opposite
order of the algorithm names in the identifier order of the algorithm names in the identifier
"AES_CBC_HMAC_SHA2". "AES_CBC_HMAC_SHA2".
2. The Initialization Vector (IV) used is a 128 bit value generated 2. The Initialization Vector (IV) used is a 128 bit value generated
randomly or pseudorandomly for use in the cipher. randomly or pseudorandomly for use in the cipher.
3. The plaintext is CBC encrypted using PKCS #5 padding using 3. The plaintext is CBC encrypted using PKCS #7 padding using
ENC_KEY as the key, and the IV. We denote the ciphertext output ENC_KEY as the key, and the IV. We denote the ciphertext output
from this step as E. from this step as E.
4. The octet string AL is equal to the number of bits in A expressed 4. The octet string AL is equal to the number of bits in A expressed
as a 64-bit unsigned integer in network byte order. as a 64-bit unsigned integer in network byte order.
5. A message authentication tag T is computed by applying HMAC 5. A message authentication tag T is computed by applying HMAC
[RFC2104] to the following data, in order: [RFC2104] to the following data, in order:
the additional authenticated data A, the additional authenticated data A,
skipping to change at page 25, line 34 skipping to change at page 25, line 34
computing an HMAC with the inputs as in Step 5 of computing an HMAC with the inputs as in Step 5 of
Section 5.2.2.1. The value T, from the previous step, is Section 5.2.2.1. The value T, from the previous step, is
compared to the first MAC_KEY length bits of the HMAC output. If compared to the first MAC_KEY length bits of the HMAC output. If
those values are identical, then A and E are considered valid, those values are identical, then A and E are considered valid,
and processing is continued. Otherwise, all of the data used in and processing is continued. Otherwise, all of the data used in
the MAC validation are discarded, and the AEAD decryption the MAC validation are discarded, and the AEAD decryption
operation returns an indication that it failed, and the operation operation returns an indication that it failed, and the operation
halts. (But see Section 11.2 of [JWE] for security halts. (But see Section 11.2 of [JWE] for security
considerations on thwarting timing attacks.) considerations on thwarting timing attacks.)
3. The value E is decrypted and the PKCS #5 padding is removed. The 3. The value E is decrypted and the PKCS #7 padding is removed. The
value IV is used as the initialization vector. The value ENC_KEY value IV is used as the initialization vector. The value ENC_KEY
is used as the decryption key. is used as the decryption key.
4. The plaintext value is returned. 4. The plaintext value is returned.
5.2.3. AES_128_CBC_HMAC_SHA_256 5.2.3. AES_128_CBC_HMAC_SHA_256
This algorithm is a concrete instantiation of the generic This algorithm is a concrete instantiation of the generic
AES_CBC_HMAC_SHA2 algorithm above. It uses the HMAC message AES_CBC_HMAC_SHA2 algorithm above. It uses the HMAC message
authentication code [RFC2104] with the SHA-256 hash function [SHS] to authentication code [RFC2104] with the SHA-256 hash function [SHS] to
provide message authentication, with the HMAC output truncated to 128 provide message authentication, with the HMAC output truncated to 128
bits, corresponding to the HMAC-SHA-256-128 algorithm defined in bits, corresponding to the HMAC-SHA-256-128 algorithm defined in
[RFC4868]. For encryption, it uses AES in the Cipher Block Chaining [RFC4868]. For encryption, it uses AES in the Cipher Block Chaining
(CBC) mode of operation as defined in Section 6.2 of [NIST.800-38A], (CBC) mode of operation as defined in Section 6.2 of [NIST.800-38A],
with PKCS #5 padding and a 128 bit initialization vector (IV) value. with PKCS #7 padding and a 128 bit initialization vector (IV) value.
The AES_CBC_HMAC_SHA2 parameters specific to AES_128_CBC_HMAC_SHA_256 The AES_CBC_HMAC_SHA2 parameters specific to AES_128_CBC_HMAC_SHA_256
are: are:
The input key K is 32 octets long. The input key K is 32 octets long.
ENC_KEY_LEN is 16 octets. ENC_KEY_LEN is 16 octets.
MAC_KEY_LEN is 16 octets. MAC_KEY_LEN is 16 octets.
skipping to change at page 48, line 40 skipping to change at page 48, line 40
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 faced by any cryptographic application
must be faced by a JWS/JWE/JWK agent. Among these issues are must be faced by a JWS/JWE/JWK agent. Among these issues are
protecting the user's private and symmetric keys, preventing various protecting the user's asymmetric private and symmetric secret keys,
attacks, and helping the user avoid mistakes such as inadvertently preventing various attacks, and helping avoid mistakes such as
encrypting a message for the wrong recipient. The entire list of inadvertently encrypting a message to the wrong recipient. The
security considerations is beyond the scope of this document, but entire list of security considerations is beyond the scope of this
some significant considerations are listed here. 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.
Algorithms of matching strengths should be used together whenever
possible. For instance, when AES Key Wrap is used with a given key
size, using the same key size is recommended when AES GCM is also
used.
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
and will be deprecated. Therefore, implementers and deployments must and will be deprecated. Therefore, implementers and deployments must
be prepared for this eventuality. be prepared for this eventuality.
8.2. Key Lifetimes 8.2. Key Lifetimes
Many algorithms have associated security considerations related to Many algorithms have associated security considerations related to
skipping to change at page 50, line 37 skipping to change at page 50, line 31
HTTPS with client authentication. It requires a JWS signature on HTTPS with client authentication. It requires a JWS signature on
objects received over HTTP, but accepts plaintext JWS objects over objects received over HTTP, but accepts plaintext JWS objects over
HTTPS. If the application were to globally indicate that "none" is HTTPS. If the application were to globally indicate that "none" is
acceptable, then an attacker could provide it with an unsigned object acceptable, then an attacker could provide it with an unsigned object
over HTTP and still have that object successfully validate. Instead, over HTTP and still have that object successfully validate. Instead,
the application needs to indicate acceptance of "none" for each the application needs to indicate acceptance of "none" for each
object received over HTTPS (e.g., by setting "acceptUnsigned" to object received over HTTPS (e.g., by setting "acceptUnsigned" to
"true" for the first hypothetical JWS software library above), but "true" for the first hypothetical JWS software library above), but
not for each object received over HTTP. not for each object received over HTTP.
8.6. Differences between Digital Signatures and MACs 8.6. Denial of Service Attacks
While in many cases, MACs and digital signatures can be used for
integrity checking, there are some significant differences between
the security properties that each of them provides. These need to be
taken into consideration when designing protocols and selecting the
algorithms to be used in protocols.
Both signatures and MACs provide for integrity checking -- verifying
that the message has not been modified since the integrity value was
computed. However, MACs provide for origination identification only
under specific circumstances. It can normally be assumed that a
private key used for a signature is only in the hands of a single
entity (although perhaps a distributed entity, in the case of
replicated servers); however, a MAC key needs to be in the hands of
all the entities that use it for integrity computation and checking.
This means that origination can only be determined if a MAC key is
known only to two entities and the receiver knows that it did not
create the message. MAC validation cannot be used to prove
origination to a third party.
8.7. 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
send certificates with keys that would result in excessive send certificates with 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, which could swamp the processing mandated in this specification, which could swamp the processing
element. Agents that use such keys without first validating the element. Agents that use such keys without first validating the
certificate to a trust anchor are advised to have some sort of certificate to a trust anchor are advised to have some sort of
cryptographic resource management system to prevent such attacks. cryptographic resource management system to prevent such attacks.
8.8. 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 [RFC4086].
8.9. 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
[RFC2898] to derive cryptographic keys from user-supplied passwords. [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.
skipping to change at page 52, line 12 skipping to change at page 51, line 33
used for "PBES2-HS512+A256KW" be no shorter than 32 octets and no used for "PBES2-HS512+A256KW" be no shorter than 32 octets and no
longer than 128 octets long. longer than 128 octets long.
Still, care needs to be taken in where and how password-based Still, care needs to be taken in where and how password-based
encryption is used. These algorithms can still be susceptible to encryption is used. These algorithms can still be susceptible to
dictionary-based attacks if the iteration count is too small; this is dictionary-based attacks if the iteration count is too small; this is
of particular concern if these algorithms are used to protect data of particular concern if these algorithms are used to protect data
that an attacker can have indefinite number of attempts to circumvent that an attacker can have indefinite number of attempts to circumvent
the protection, such as protected data stored on a file system. the protection, such as protected data stored on a file system.
8.10. Adaptive Chosen-Ciphertext Attacks 8.9. Key Entropy
See Section 11.1 of [JWE] for security considerations on adaptive See Section 10.1 of [JWS] for security considerations on key entropy.
8.10. Differences between Digital Signatures and MACs
See Section 10.4 of [JWS] for security considerations on differences
between digital signatures and MACs.
8.11. Using Matching Algorithm Strengths
See Section 11.1 of [JWE] for security considerations on using
matching algorithm strengths.
8.12. Adaptive Chosen-Ciphertext Attacks
See Section 11.2 of [JWE] for security considerations on adaptive
chosen-ciphertext attacks. chosen-ciphertext attacks.
8.11. Timing Attacks 8.13. Timing Attacks
See Section 11.2 of [JWE] for security considerations on timing See Section 10.3 of [JWS] and Section 11.3 of [JWE] for security
attacks. considerations on timing attacks.
8.12. RSA Private Key Representations and Blinding 8.14. RSA Private Key Representations and Blinding
See Section 9.3 of [JWK] for security considerations on RSA private See Section 9.3 of [JWK] for security considerations on RSA private
key representations and blinding. key representations and blinding.
9. Internationalization Considerations 9. Internationalization Considerations
Passwords obtained from users are likely to require preparation and Passwords obtained from users are likely to require preparation and
normalization to account for differences of octet sequences generated normalization to account for differences of octet sequences generated
by different input devices, locales, etc. It is RECOMMENDED that by different input devices, locales, etc. It is RECOMMENDED that
applications to perform the steps outlined in applications to perform the steps outlined in
skipping to change at page 65, line 27 skipping to change at page 65, line 27
Nat Sakimura, Jim Schaad, Hannes Tschofenig, and Sean Turner. 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 ]]
-28
o Specified the use of PKCS #7 padding with AES CBC, rather than
PKCS #5. (PKCS #7 is a superset of PKCS #5, and is appropriate
for the 16 octet blocks used by AES CBC.)
o Revised the introduction to the Security Considerations section.
Also introduced additional subsection headings for security
considerations items and moved a few security consideration items
from here to the JWS and JWE drafts.
-27 -27
o Described additional security considerations. o Described additional security considerations.
o Updated the JCA and XMLENC parameters for "RSA-OAEP-256" and the o Updated the JCA and XMLENC parameters for "RSA-OAEP-256" and the
JCA parameters for "A128KW", "A192KW", "A256KW", and "ECDH-ES". JCA parameters for "A128KW", "A192KW", "A256KW", and "ECDH-ES".
-26 -26
o Added algorithm identifier "RSA-OAEP-256" for RSAES OAEP using o Added algorithm identifier "RSA-OAEP-256" for RSAES OAEP using
 End of changes. 22 change blocks. 
60 lines changed or deleted 60 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/