< draft-jones-cose-rsa-03.txt		draft-jones-cose-rsa-05.txt >
	COSE Working Group M. Jones		COSE Working Group M. Jones
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Intended status: Standards Track May 18, 2017		Intended status: Standards Track June 22, 2017
	Expires: November 19, 2017		Expires: December 24, 2017
	Using RSA Algorithms with COSE Messages		Using RSA Algorithms with COSE Messages
	draft-jones-cose-rsa-03		draft-jones-cose-rsa-05
	Abstract		Abstract
	The CBOR Object Signing and Encryption (COSE) specification defines		The CBOR Object Signing and Encryption (COSE) specification defines
	cryptographic message encodings using Concise Binary Object		cryptographic message encodings using Concise Binary Object
	Representation (CBOR). This specification defines algorithm		Representation (CBOR). This specification defines algorithm
	encodings and representations enabling RSA algorithms to be used for		encodings and representations enabling RSA algorithms to be used for
	COSE messages. Encodings for the use of RSASSA-PSS signatures,		COSE messages. Encodings for the use of RSASSA-PSS signatures,
	RSAES-OAEP encryption, and RSA keys are specified.		RSAES-OAEP encryption, and RSA keys are specified.
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 19, 2017.		This Internet-Draft will expire on December 24, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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 15 ¶		skipping to change at page 2, line 15 ¶
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Notation and Conventions . . . . . . . . . . 2		1.1. Requirements Notation and Conventions . . . . . . . . . . 2
	2. RSASSA-PSS Signature Algorithm . . . . . . . . . . . . . . . 2		2. RSASSA-PSS Signature Algorithm . . . . . . . . . . . . . . . 2
	3. RSAES-OAEP Key Encryption Algorithm . . . . . . . . . . . . . 3		3. RSAES-OAEP Key Encryption Algorithm . . . . . . . . . . . . . 3
	4. RSA Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 4		4. RSA Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	5.1. COSE Algorithms Registry . . . . . . . . . . . . . . . . 5		5.1. COSE Algorithms Registrations . . . . . . . . . . . . . . 5
	5.2. COSE Key Type Registry . . . . . . . . . . . . . . . . . 5		5.2. COSE Key Type Registrations . . . . . . . . . . . . . . . 6
	5.3. COSE Key Type Parameters Registry . . . . . . . . . . . . 5		5.3. COSE Key Type Parameters Registrations . . . . . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	6.1. Key Size Security Considerations . . . . . . . . . . . . 6		6.1. Key Size Security Considerations . . . . . . . . . . . . 8
	6.2. RSASSA-PSS Security Considerations . . . . . . . . . . . 6		6.2. RSASSA-PSS Security Considerations . . . . . . . . . . . 9
	6.3. RSAES-OAEP Security Considerations . . . . . . . . . . . 6		6.3. RSAES-OAEP Security Considerations . . . . . . . . . . . 9
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	7.1. Normative References . . . . . . . . . . . . . . . . . . 7		7.1. Normative References . . . . . . . . . . . . . . . . . . 9
	7.2. Informative References . . . . . . . . . . . . . . . . . 7		7.2. Informative References . . . . . . . . . . . . . . . . . 10
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10
	Appendix B. Document History . . . . . . . . . . . . . . . . . . 7		Appendix B. Document History . . . . . . . . . . . . . . . . . . 10
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	The CBOR Object Signing and Encryption (COSE) [I-D.ietf-cose-msg]		The CBOR Object Signing and Encryption (COSE) [I-D.ietf-cose-msg]
	specification defines cryptographic message encodings using Concise		specification defines cryptographic message encodings using Concise
	Binary Object Representation (CBOR) [RFC7049]. This specification		Binary Object Representation (CBOR) [RFC7049]. This specification
	defines algorithm encodings and representations enabling RSA		defines algorithm encodings and representations enabling RSA
	algorithms to be used for COSE messages.		algorithms to be used for COSE messages.
	1.1. Requirements Notation and Conventions		1.1. Requirements Notation and Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in RFC		"OPTIONAL" in this document are to be interpreted as described in RFC
	2119 [RFC2119].		2119 [RFC2119].
	2. RSASSA-PSS Signature Algorithm		2. RSASSA-PSS Signature Algorithm
	The RSASSA-PSS signature algorithm is defined in [RFC3447].		The RSASSA-PSS signature algorithm is defined in [RFC8017].
	The RSASSA-PSS signature algorithm is parameterized with a hash		The RSASSA-PSS signature algorithm is parameterized with a hash
	function (h), a mask generation function (mgf) and a salt length		function (h), a mask generation function (mgf) and a salt length
	(sLen). For this specification, the mask generation function is		(sLen). For this specification, the mask generation function is
	fixed to be MGF1 as defined in [RFC3447]. It has been recommended		fixed to be MGF1 as defined in [RFC8017]. It has been recommended
	that the same hash function be used for hashing the data as well as		that the same hash function be used for hashing the data as well as
	in the mask generation function. This specification follows this		in the mask generation function. This specification follows this
	recommendation. The salt length is the same length as the hash		recommendation. The salt length is the same length as the hash
	function output.		function output.
	Implementations need to check that the key type is 'RSA' when		Implementations need to check that the key type is 'RSA' when
	creating or verifying a signature.		creating or verifying a signature.
	The algorithms defined in this document can be found in Table 1.		The RSASSA-PSS algorithms specified in this document are in the
			following table.
	+-------+-------+---------+-------------+-----------------------+		+-------+-------+---------+-------------+-----------------------+
	| Name | Value | Hash | Salt Length | Description |		| Name | Value | Hash | Salt Length | Description |
	+-------+-------+---------+-------------+-----------------------+		+-------+-------+---------+-------------+-----------------------+
	| PS256 | -37 | SHA-256 | 32 | RSASSA-PSS w/ SHA-256 |		| PS256 | -37 | SHA-256 | 32 | RSASSA-PSS w/ SHA-256 |
	| PS384 | -38 | SHA-384 | 48 | RSASSA-PSS w/ SHA-384 |		| PS384 | -38 | SHA-384 | 48 | RSASSA-PSS w/ SHA-384 |
	| PS512 | -39 | SHA-512 | 64 | RSASSA-PSS w/ SHA-512 |		| PS512 | -39 | SHA-512 | 64 | RSASSA-PSS w/ SHA-512 |
	+-------+-------+---------+-------------+-----------------------+		+-------+-------+---------+-------------+-----------------------+
	Table 1: RSASSA-PSS Algorithm Values		Table 1: RSASSA-PSS Algorithm Values
	3. RSAES-OAEP Key Encryption Algorithm		3. RSAES-OAEP Key Encryption Algorithm
	RSAES-OAEP is an asymmetric key encryption algorithm. The definition		RSAES-OAEP is an asymmetric key encryption algorithm. The definition
	of RSAEA-OAEP can be find in Section 7.1 of [RFC3447]. The algorithm		of RSAEA-OAEP can be found in Section 7.1 of [RFC8017]. The
	is parameterized using a masking generation function (mgf), a hash		algorithm is parameterized using a masking generation function (mgf),
	function (h) and encoding parameters (P). For the algorithm		a hash function (h) and encoding parameters (P). For the algorithm
	identifiers defined in this section:		identifiers defined in this section:
	o mgf is always set to MFG1 from [RFC3447] and uses the same hash		o mgf is always set to MGF1 from [RFC8017] and uses the same hash
	function as h.		function as h.
	o P is always set to the empty octet string.		o P is always set to the empty octet string.
	Table 2 summarizes the rest of the values.		The following table summarizes the rest of the values.
	+-------------------------------+-------+---------+-----------------+		+-------------------------------+-------+---------+-----------------+
	| Name | Value | Hash | Description |		| Name | Value | Hash | Description |
	+-------------------------------+-------+---------+-----------------+		+-------------------------------+-------+---------+-----------------+
	| RSAES-OAEP w/ RFC 3447 | -40 | SHA-1 | RSAES OAEP w/ |		| RSAES-OAEP w/ RFC 8017 | -40 | SHA-1 | RSAES-OAEP w/ |
	| default parameters | | | SHA-1 |		| default parameters | | | SHA-1 |
	| RSAES-OAEP w/ SHA-256 | -41 | SHA-256 | RSAES OAEP w/ |		| RSAES-OAEP w/ SHA-256 | -41 | SHA-256 | RSAES-OAEP w/ |
	| | | | SHA-256 |		| | | | SHA-256 |
	| RSAES-OAEP w/ SHA-512 | -42 | SHA-512 | RSAES OAEP w/ |		| RSAES-OAEP w/ SHA-512 | -42 | SHA-512 | RSAES-OAEP w/ |
	| | | | SHA-512 |		| | | | SHA-512 |
	+-------------------------------+-------+---------+-----------------+		+-------------------------------+-------+---------+-----------------+
	Table 2: RSAES-OAEP Algorithm Values		Table 2: RSAES-OAEP Algorithm Values
	The key type MUST be 'RSA'.		The key type MUST be 'RSA'.
	4. RSA Keys		4. RSA Keys
	Key types are identified by the 'kty' member of the COSE_Key object.		Key types are identified by the 'kty' member of the COSE_Key object.
	This specification defines one value for this member.		This specification defines one value for this member in the following
			table.
	+------+-------+-------------+		+------+-------+-------------+
	| Name | Value | Description |		| Name | Value | Description |
	+------+-------+-------------+		+------+-------+-------------+
	| RSA | 3 | RSA Key |		| RSA | 3 | RSA Key |
	+------+-------+-------------+		+------+-------+-------------+
	Table 3: Key Type Values		Table 3: Key Type Values
	This document defines a key structure for both the public and private		This document defines a key structure for both the public and private
	parts of RSA keys. Together, an RSA public key and an RSA private		parts of RSA keys. Together, an RSA public key and an RSA private
	key form an RSA key pair.		key form an RSA key pair.
	The document also provides support for the so-called "multi-prime"		The document also provides support for the so-called "multi-prime"
	RSA keys, in which the modulus may have more than two prime factors.		RSA keys, in which the modulus may have more than two prime factors.
	The benefit of multi-prime RSA is lower computational cost for the		The benefit of multi-prime RSA is lower computational cost for the
	decryption and signature primitives. For a discussion on how multi-		decryption and signature primitives. For a discussion on how multi-
	prime affects the security of RSA crypto-systems, the reader is		prime affects the security of RSA crypto-systems, the reader is
	referred to [MultiPrimeRSA].		referred to [MultiPrimeRSA].
	This document follows the naming convention of [RFC3447] for the		This document follows the naming convention of [RFC8017] for the
	naming of the fields of an RSA public or private key. Table 4		naming of the fields of an RSA public or private key and the
	provides a summary of the label values and the types associated with		corresponding fields have identical semantics. The requirements for
	each of those labels. The requirements for fields for RSA keys are		fields for RSA keys are as follows:
	as follows:
	o For all keys, 'kty' MUST be present and MUST have a value of 3.		o For all keys, 'kty' MUST be present and MUST have a value of 3.
	o For public keys, the fields 'n' and 'e' MUST be present. All		o For public keys, the fields 'n' and 'e' MUST be present. All
	other fields defined in Table 4 MUST be absent.		other fields defined in the following table below MUST be absent.
	o For private keys with two primes, the fields 'other', 'r_i', 'd_i'		o For private keys with two primes, the fields 'other', 'r_i', 'd_i'
	and 't_i' MUST be absent; all other fields MUST be present.		and 't_i' MUST be absent; all other fields MUST be present.
	o For private keys with more than two primes, all fields MUST be		o For private keys with more than two primes, all fields MUST be
	present. For the third to nth primes, each of the primes is		present. For the third to nth primes, each of the primes is
	represented as a map containing the fields 'r_i', 'd_i' and 't_i'.		represented as a map containing the fields 'r_i', 'd_i' and 't_i'.
	The field 'other' is an array of those maps.		The field 'other' is an array of those maps.
	o All numeric key parameters are encoded in an unsigned big-endian		o All numeric key parameters are encoded in an unsigned big-endian
	representation as an octet sequence using the CBOR byte string		representation as an octet sequence using the CBOR byte string
	type (major type 2). The octet sequence MUST utilize the minimum		type (major type 2). The octet sequence MUST utilize the minimum
	number of octets needed to represent the value. For instance, the		number of octets needed to represent the value. For instance, the
	value 32,768 is represented as the CBOR byte sequence 0b010_00010		value 32,768 is represented as the CBOR byte sequence 0b010_00010,
	(major type 2, additional information 2 for the length), 0x80		0x80 0x00 (major type 2, additional information 2 for the length).
	0x00.
	+-------+----------+-------+-------+--------------------------------+		The following table provides a summary of the label values and the
	| Name | Key Type | Value | Type | Description |		types associated with each of those labels.
	+-------+----------+-------+-------+--------------------------------+
	| n | 3 | -1 | bstr | Modulus Parameter |		+-------+-------+-------+-------+-----------------------------------+
	| e | 3 | -2 | bstr | Exponent Parameter |		| Key | Name | Label | CBOR | Description |
	| d | 3 | -3 | bstr | Private Exponent Parameter |		| Type | | | Type | |
	| p | 3 | -4 | bstr | First Prime Factor |		+-------+-------+-------+-------+-----------------------------------+
	| q | 3 | -5 | bstr | Second Prime Factor |		| 3 | n | -1 | bstr | the RSA modulus n |
	| dP | 3 | -6 | bstr | First Factor CRT Exponent |		| 3 | e | -2 | bstr | the RSA public exponent e |
	| dQ | 3 | -7 | bstr | Second Factor CRT Exponent |		| 3 | d | -3 | bstr | the RSA private exponent d |
	| qInv | 3 | -8 | bstr | First CRT Coefficient |		| 3 | p | -4 | bstr | the prime factor p of n |
	| other | 3 | -9 | array | Other Primes Info |		| 3 | q | -5 | bstr | the prime factor q of n |
	| r_i | 3 | -10 | bstr | i-th factor, Prime Factor |		| 3 | dP | -6 | bstr | dP is d mod (p - 1) |
	| d_i | 3 | -11 | bstr | i-th factor, Factor CRT |		| 3 | dQ | -7 | bstr | dQ is d mod (q - 1) |
	| | | | | Exponent |		| 3 | qInv | -8 | bstr | qInv is the CRT coefficient |
	| t_i | 3 | -12 | bstr | i-th factor, Factor CRT |		| | | | | q^(-1) mod p |
	| | | | | Coefficient |		| 3 | other | -9 | array | other prime infos, an array |
	+-------+----------+-------+-------+--------------------------------+		| 3 | r_i | -10 | bstr | a prime factor r_i of n, where i |
			| | | | | >= 3 |
			| 3 | d_i | -11 | bstr | d_i = d mod (r_i - 1) |
			| 3 | t_i | -12 | bstr | the CRT coefficient t_i = (r_1 * |
			| | | | | r_2 * ... * r_(i-1))^(-1) mod r_i |
			+-------+-------+-------+-------+-----------------------------------+
	Table 4: RSA Key Parameters		Table 4: RSA Key Parameters
	5. IANA Considerations		5. IANA Considerations
	5.1. COSE Algorithms Registry		5.1. COSE Algorithms Registrations
	This section registers values in the IANA "COSE Algorithms" registry		This section registers the following values in the IANA "COSE
	[IANA.COSE].		Algorithms" registry [IANA.COSE].
	The values in Table 1 and Table 2 are to be added to the registry.		o Name: PS256
			o Value: -37
			o Description: RSASSA-PSS w/ SHA-256
			o Reference: Section 2 of [[ this specification ]]
			o Recommended: Yes
	5.2. COSE Key Type Registry		o Name: PS384
			o Value: -38
			o Description: RSASSA-PSS w/ SHA-384
			o Reference: Section 2 of [[ this specification ]]
			o Recommended: Yes
			o Name: PS512
			o Value: -39
			o Description: RSASSA-PSS w/ SHA-512
			o Reference: Section 2 of [[ this specification ]]
			o Recommended: Yes
	This section registers values in the IANA "COSE Key Type" registry		o Name: RSAES-OAEP w/ RFC 8017 default parameters
	[IANA.COSE].		o Value: -40
			o Description: RSAES-OAEP w/ SHA-1
			o Reference: Section 3 of [[ this specification ]]
			o Recommended: Yes
	The values in Table 3 are to be added to the registry.		o Name: RSAES-OAEP w/ SHA-256
			o Value: -41
			o Description: RSAES-OAEP w/ SHA-256
			o Reference: Section 3 of [[ this specification ]]
			o Recommended: Yes
	5.3. COSE Key Type Parameters Registry		o Name: RSAES-OAEP w/ SHA-512
			o Value: -42
			o Description: RSAES-OAEP w/ SHA-512
			o Reference: Section 3 of [[ this specification ]]
			o Recommended: Yes
	This section registers values in the IANA "COSE Key Type Parameters"		5.2. COSE Key Type Registrations
	registry [IANA.COSE].
	The values in Table 4 are to be added to the registry.		This section registers the following values in the IANA "COSE Key
			Type" registry [IANA.COSE].
			o Name: RSA
			o Value: 3
			o Description: RSA Key
			o Reference: Section 4 of [[ this specification ]]
			5.3. COSE Key Type Parameters Registrations
			This section registers the following values in the IANA "COSE Key
			Type Parameters" registry [IANA.COSE].
			o Key Type: 3
			o Name: n
			o Label: -1
			o CBOR Type: bstr
			o Description: the RSA modulus n
			o Reference: Section 4 of [[ this specification ]]
			o Key Type: 3
			o Name: e
			o Label: -2
			o CBOR Type: bstr
			o Description: the RSA public exponent e
			o Reference: Section 4 of [[ this specification ]]
			o Key Type: 3
			o Name: d
			o Label: -3
			o CBOR Type: bstr
			o Description: the RSA private exponent d
			o Reference: Section 4 of [[ this specification ]]
			o Key Type: 3
			o Name: p
			o Label: -4
			o CBOR Type: bstr
			o Description: the prime factor p of n
			o Reference: Section 4 of [[ this specification ]]
			o Key Type: 3
			o Name: q
			o Label: -5
			o CBOR Type: bstr
			o Description: the prime factor q of n
			o Reference: Section 4 of [[ this specification ]]
			o Key Type: 3
			o Name: dP
			o Label: -6
			o CBOR Type: bstr
			o Description: dP is d mod (p - 1)
			o Reference: Section 4 of [[ this specification ]]
			o Key Type: 3
			o Name: dQ
			o Label: -7
			o CBOR Type: bstr
			o Description: dQ is d mod (q - 1)
			o Reference: Section 4 of [[ this specification ]]
			o Key Type: 3
			o Name: qInv
			o Label: -8
			o CBOR Type: bstr
			o Description: qInv is the CRT coefficient q^(-1) mod p
			o Reference: Section 4 of [[ this specification ]]
			o Key Type: 3
			o Name: other
			o Label: -9
			o CBOR Type: array
			o Description: other prime infos, an array
			o Reference: Section 4 of [[ this specification ]]
			o Key Type: 3
			o Name: r_i
			o Label: -10
			o CBOR Type: bstr
			o Description: a prime factor r_i of n, where i >= 3
			o Reference: Section 4 of [[ this specification ]]
			o Key Type: 3
			o Name: d_i
			o Label: -11
			o CBOR Type: bstr
			o Description: d_i = d mod (r_i - 1)
			o Reference: Section 4 of [[ this specification ]]
			o Key Type: 3
			o Name: t_i
			o Label: -12
			o CBOR Type: bstr
			o Description: the CRT coefficient t_i = (r_1 * r_2 * ... *
			r_(i-1))^(-1) mod r_i
			o Reference: Section 4 of [[ this specification ]]
	6. Security Considerations		6. Security Considerations
	6.1. Key Size Security Considerations		6.1. Key Size Security Considerations
	A key size of 2048 bits or larger MUST be used with these algorithms.		A key size of 2048 bits or larger MUST be used with these algorithms.
	This key size corresponds roughly to the same strength as provided by		This key size corresponds roughly to the same strength as provided by
	a 128-bit symmetric encryption algorithm. Implementations SHOULD be		a 128-bit symmetric encryption algorithm. Implementations SHOULD be
	able to encrypt and decrypt with modulus between 2048 and 16K bits in		able to encrypt and decrypt with modulus between 2048 and 16K bits in
	length. Applications can impose additional restrictions on the		length. Applications can impose additional restrictions on the
	skipping to change at page 6, line 25 ¶		skipping to change at page 9, line 4 ¶
	In addition to needing to worry about keys that are too small to		In addition to needing to worry about keys that are too small to
	provide the required security, there are issues with keys that are		provide the required security, there are issues with keys that are
	too large. Denial of service attacks have been mounted with overly		too large. Denial of service attacks have been mounted with overly
	large keys or oddly sized keys. This has the potential to consume		large keys or oddly sized keys. This has the potential to consume
	resources with these keys. It is highly recommended that checks on		resources with these keys. It is highly recommended that checks on
	the key length be done before starting a cryptographic operation.		the key length be done before starting a cryptographic operation.
	There are two reasonable ways to address this attack. First, a key		There are two reasonable ways to address this attack. First, a key
	should not be used for a cryptographic operation until it has been		should not be used for a cryptographic operation until it has been
	verified that it is controlled by a legitimate participant. This		verified that it is controlled by a party trusted by the recipient.
	approach means that no cryptography would be done except with keys of		This approach means that no cryptography will be done until a trust
	legitimate parties. Second, applications can impose maximum as well		decision about the key has been made, a process described in
	as minimum length requirements on keys. This limits the resources		Appendix D, Item 4 of [RFC7515]. Second, applications can impose
	that would otherwise be consumed by the use of overly large keys.		maximum as well as minimum length requirements on keys. This limits
			the resources that would otherwise be consumed by the use of overly
			large keys.
	6.2. RSASSA-PSS Security Considerations		6.2. RSASSA-PSS Security Considerations
	There is a theoretical hash substitution attack that can be mounted		There is a theoretical hash substitution attack that can be mounted
	against RSASSA-PSS. However, the requirement that the same hash		against RSASSA-PSS [HASHID]. However, the requirement that the same
	function be used consistently for all operations is an effective		hash function be used consistently for all operations is an effective
	mitigation against it. Unlike ECDSA, hash function outputs are not		mitigation against it. Unlike ECDSA, hash function outputs are not
	truncated so that the full hash value is always signed. The internal		truncated so that the full hash value is always signed. The internal
	padding structure of RSASSA-PSS means that one needs to have multiple		padding structure of RSASSA-PSS means that one needs to have multiple
	collisions between the two hash functions to be successful in		collisions between the two hash functions to be successful in
	producing a forgery based on changing the hash function. This is		producing a forgery based on changing the hash function. This is
	highly unlikely.		highly unlikely.
	6.3. RSAES-OAEP Security Considerations		6.3. RSAES-OAEP Security Considerations
	A version of RSAES-OAEP using the default parameters specified in		A version of RSAES-OAEP using the default parameters specified in
	Appendix A.2.1 of RFC 3447 is included because this is the most		Appendix A.2.1 of RFC 8017 is included because this is the most
	widely implemented set of OAEP parameter choices. (Those default		widely implemented set of OAEP parameter choices. (Those default
	parameters are the SHA-1 hash function and the MGF1 with SHA-1 mask		parameters are the SHA-1 hash function and the MGF1 with SHA-1 mask
	generation function.) While SHA-1 is deprecated as a general-purpose		generation function.)
	hash function, no known practical attacks are enabled by its use in
	this context.		Keys used with RSAES-OAEP MUST follow the constraints in Section 7.1
			of RFC 8017. Also, keys with a low private key exponent value, as
			described in Section 3 of "Twenty Years of Attacks on the RSA
			Cryptosystem" [Boneh99], MUST NOT be used.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
			[Boneh99] Boneh, D., "Twenty Years of Attacks on the RSA
			Cryptosystem", Notices of the American Mathematical
			Society (AMS), Vol. 46, No. 2, pp. 203-213, 1999,
			<http://crypto.stanford.edu/~dabo/pubs/papers/
			RSA-survey.pdf>.
	[I-D.ietf-cose-msg]		[I-D.ietf-cose-msg]
	Schaad, J., "CBOR Object Signing and Encryption (COSE)",		Schaad, J., "CBOR Object Signing and Encryption (COSE)",
	draft-ietf-cose-msg-24 (work in progress), November 2016.		draft-ietf-cose-msg-24 (work in progress), November 2016.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
	Standards (PKCS) #1: RSA Cryptography Specifications
	Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
	2003, <http://www.rfc-editor.org/info/rfc3447>.
	[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object		[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,		Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
	October 2013, <http://www.rfc-editor.org/info/rfc7049>.		October 2013, <http://www.rfc-editor.org/info/rfc7049>.
			[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
			Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
			2015, <http://www.rfc-editor.org/info/rfc7515>.
			[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
			"PKCS #1: RSA Cryptography Specifications Version 2.2",
			RFC 8017, DOI 10.17487/RFC8017, November 2016,
			<http://www.rfc-editor.org/info/rfc8017>.
	7.2. Informative References		7.2. Informative References
			[HASHID] Kaliski, B., "On Hash Function Firewalls in Signature
			Schemes", Lecture Notes in Computer Science, Volume
			2271, pp. 1-16, DOI 10.1007/3-540-45760-7_1, February
			2002, <https://rd.springer.com/
			chapter/10.1007/3-540-45760-7_1>.
	[IANA.COSE]		[IANA.COSE]
	IANA, "CBOR Object Signing and Encryption (COSE)",		IANA, "CBOR Object Signing and Encryption (COSE)",
	<http://www.iana.org/assignments/cose>.		<http://www.iana.org/assignments/cose>.
	[MultiPrimeRSA]		[MultiPrimeRSA]
	Hinek, M. and D. Cheriton, "On the Security of Multi-prime		Hinek, M. and D. Cheriton, "On the Security of Multi-prime
	RSA", June 2006.		RSA", June 2006.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	This specification incorporates text from draft-ietf-cose-msg-05 by		This specification incorporates text from draft-ietf-cose-msg-05 by
	Jim Schaad. Thanks are due to Kathleen Moriarty, Rich Salz, and Jim		Jim Schaad. Thanks are due to Ben Campbell, Roni Even, Steve Kent,
			Kathleen Moriarty, Eric Rescorla, Adam Roach, Rich Salz, and Jim
	Schaad for their reviews of the specification.		Schaad for their reviews of the specification.
	Appendix B. Document History		Appendix B. Document History
	[[ to be removed by the RFC Editor before publication as an RFC ]]		[[ to be removed by the RFC Editor before publication as an RFC ]]
			-05
			o Addressed IESG review comments.
			o Updated the RFC 3447 reference to RFC 8017.
			o Updated the field descriptions to use the wording from
			Section A.1.2 of RFC 8017.
			o Corrected an error in the RSAES-OAEP security considerations.
			-04
			o Addressed SecDir review comments by Steve Kent and Gen-ART review
			comments by Roni Even.
	-03		-03
	o Clarified the Security Considerations in ways suggested by		o Clarified the Security Considerations in ways suggested by
	Kathleen Moriarty.		Kathleen Moriarty.
	o Acknowledged reviewers.		o Acknowledged reviewers.
	-02		-02
	o Reorganized the security considerations.		o Reorganized the security considerations.
End of changes. 37 change blocks.
	85 lines changed or deleted		247 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/