Draft: draft-ietf-cose-msg

Commentary: Remove RSA algorithms to be placed in the second draft algorithms document .
The RSASSA-PSS signature algorithm is defined in RFC3447.
The RSASSA-PSS signature algorithm is parameterized with a hash
function (h), a mask generation function (mgf) and a salt length
(sLen).  For this specification, the mask generation function is
fixed to be MGF1 as defined in RFC3447.  It has been recommended that
the same hash function be used for hashing the data as well as in the
mask generation function, for this specification we following this
recommendation.  The salt length is the same length as the hash
function output.
Implementations need to check that the key type is 'RSA' when
creating or verifying a signature.
The algorithms defined in this document can be found in table-rsa-
algs.
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.  This has the potential to consume resources with
potentially bad keys.  There are two reasonable ways to address this
attack.  First, a key should not be used for a cryptographic
operation until it has been matched back to an authorized user.  This
approach means that no cryptography would be done except for
authorized users.  Second, applications can impose maximum as well as
minimum length requirements on keys.  This limits the resources
consumed even if the matching is not performed until the cryptography
has been done.
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 functions 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 in order to be successful
in producing a forgery based on changing the hash function.  This is
highly unlikely.
mgf is always set to MFG1 from RFC3447 and uses the same hash
function as h.
P is always set to the empty octet string.
table-RSA-OAEP summarizes the rest of the values.
The key type MUST be 'RSA'.
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.
It is highly recommended that checks on the key length be done before
starting a decryption operation.  One potential denial of service
operation is to provide encrypted objects using either abnormally
long or oddly sized RSA modulus values.  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.
This document defines a key structure for both the public and private
halves of RSA keys.  Together, an RSA public key and an RSA private
key form an RSA key pair.
The document also provides support for the so-called "multi-prime"
RSA where the modulus may have more than two prime factors.  The
benefit of multi-prime RSA is lower computational cost for the
decryption and signature primitives.  For a discussion on how multi-
prime affects the security of RSA crypto-systems, the reader is
referred to MultiPrimeRSA.
For all keys, 'kty' MUST be present and MUST have a value of 3.
For public keys, the fields 'n' and 'e' MUST be present.  All
other fields defined in table-rsa-keys MUST be absent.
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.
For private keys with more than two primes, all fields MUST be
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'.
The field 'other' is an array of those maps.
The initial contents of the registry can be found in the following:
table-AES-CCM, table-AES-GCM, Table-CHACHA, table_ecdsa, table-rsa-
algs, table-hmac, table-aes-mac, table-direct, table-direct-kdf,
table_aes_keywrap, table-RSA-OAEP, table-ecdh-es-table.  The
specification column for all rows in that table should be this
document.
The initial contents of the registry can be found in the following:
table-AES-CCM, table-AES-GCM, Table-CHACHA, table_ecdsa, table-hmac,
table-aes-mac, table-direct, table-direct-kdf, table_aes_keywrap,
table-ecdh-es-table.  The specification column for all rows in that
table should be this document.
This registry will be initially populated by the values in table-
ec2-keys, table-rsa-keys, and table-symmetric-keys.  The
specification column for all of these entries will be this document.
This registry will be initially populated by the values in table-
ec2-keys, and table-symmetric-keys.  The specification column for all
of these entries will be this document.