RSA Key Parameters

Name	Key Type	Value	Type	Description
n	3	-1	bstr	Modulus Parameter
e	3	-2	bstr	Exponent Parameter
d	3	-3	bstr	Private Exponent Parameter
p	3	-4	bstr	First Prime Factor
q	3	-5	bstr	Second Prime Factor
dP	3	-6	bstr	First Factor CRT Exponent
dQ	3	-7	bstr	Second Factor CRT Exponent
qInv	3	-8	bstr	First CRT Coefficient
other	3	-9	array	Other Primes Info
r_i	3	-10	bstr	i-th factor, Prime Factor
d_i	3	-11	bstr	i-th factor, Factor CRT Exponent
t_i	3	-12	bstr	i-th factor, Factor CRT Coefficient

5. IANA Considerations

5.1. COSE Algorithms Registry

This section registers values in the IANA "COSE Algorithms" registry [IANA.COSE].

The values in Table 1 and Table 2 are to be added to the registry.

5.2. COSE Key Type Registry

This section registers values in the IANA "COSE Key Type" registry [IANA.COSE].

The values in Table 3 are to be added to the registry.

5.3. COSE Key Type Parameters Registry

This section registers values in the IANA "COSE Key Type Parameters" registry [IANA.COSE].

The values in Table 4 are to be added to the registry.

6. Security Considerations

6.1. Key Size Security Considerations

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 a 128-bit symmetric encryption algorithm. Implementations SHOULD be able to encrypt and decrypt with modulus between 2048 and 16K bits in length. Applications can impose additional restrictions on the length of the modulus.

In addition to needing to worry about keys that are too small to provide the required security, there are issues with keys that are too large. Denial of service attacks have been mounted with overly large keys or oddly sized keys. This has the potential to consume resources with these keys. It is highly recommended that checks on the key length be done before starting a cryptographic operation.

There are two reasonable ways to address this attack. First, a key should not be used for a cryptographic operation until it has been verified that it is controlled by a legitimate participant. This approach means that no cryptography would be done except with keys of legitimate parties. Second, applications can impose 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

There is a theoretical hash substitution attack that can be mounted against RSASSA-PSS. However, the requirement that the same hash function be used consistently for all operations is an effective mitigation against it. Unlike ECDSA, hash function outputs are not truncated so that the full hash value is always signed. The internal padding structure of RSASSA-PSS means that one needs to have multiple collisions between the two hash functions to be successful in producing a forgery based on changing the hash function. This is highly unlikely.

6.3. RSAES-OAEP Security Considerations

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 widely implemented set of OAEP parameter choices. (Those default 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 hash function, no known practical attacks are enabled by its use in this context.

7. References

7.1. Normative References

[I-D.ietf-cose-msg]	Schaad, J., "CBOR Object Signing and Encryption (COSE)", Internet-Draft draft-ietf-cose-msg-24, November 2016.
[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[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.
[RFC7049]	Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013.

7.2. Informative References

[IANA.COSE]	IANA, "CBOR Object Signing and Encryption (COSE)"
[MultiPrimeRSA]	Hinek, M. and D. Cheriton, "On the Security of Multi-prime RSA", June 2006.

Appendix A. Acknowledgements

This specification incorporates text from draft-ietf-cose-msg-05 by Jim Schaad. Thanks are due to Kathleen Moriarty, Rich Salz, and Jim Schaad for their reviews of the specification.

Appendix B. Document History

[[ to be removed by the RFC Editor before publication as an RFC ]]

-03

• Clarified the Security Considerations in ways suggested by Kathleen Moriarty.
• Acknowledged reviewers.

-02

• Reorganized the security considerations.
• Flattened the section structure.
• Applied wording improvements suggested by Jim Schaad.

-01

• Completed the sets of IANA registration requests.
• Revised the algorithm assignments based on those in draft-ietf-cose-msg-24.

-00

• This specification addresses COSE issue #21: Restore RSA-PSS and the "RSA" key type. The initial version of this specification incorporates text from draft-ietf-cose-msg-05 -- the last COSE message specification version before the RSA algorithms were removed.

Author's Address