Draft: draft-ietf-cose-msg

Commentary: Expand the text and make assignments for RSA
The RSASSA-PSS signature algorithm is parametized with a hash
function, a mask generation function 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.
This uses the hash algorithm SHA-256 for signature processing.
The value used for this algorithm is -10.  The key type used for
this algorithm is 'RSA'.
This uses the hash algorithm SHA-384 for signature processing.
The value used for this algorithm is "PS384".  The key type used
for this algorithm is 'RSA'.
This uses the hash algorithm SHA-512 for signature processing.
The value used for this algorithm is -11.  The key type used for
this algorithm is 'RSA'.
There are no algorithm parameters defined for these signature
algorithms.  A summary of the algorithm definitions can be found in
table-rsa-algs.
Key size.  is there a MUST for 2048? or do we need to specify a
minimum here?
The RSASSA-PSS signature algorithm is parametized 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.
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.
Key Encryption mode is also called key transport mode in some
standards.  Key Encryption mode differs from Key Wrap mode in that it
uses an asymmetric encryption algorithm rather than a symmetric
encryption algorithm to protect the key.  The only current Key
Encryption mode algorithm supported is RSAES-OAEP.
Key Encryption mode is also called key transport mode in some
standards.  Key Encryption mode differs from Key Wrap mode in that it
uses an asymmetric encryption algorithm rather than a symmetric
encryption algorithm to protect the key.  This document defines one
Key Encryption mode algorithm.
A key size of 2048 bits or larger MUST be used with this algorithm.
This key size corresponds roughly to the same strength as provided by
a 128-bit symmetric encryption algorithm.
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.
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.
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.
This section registers the "application/cose" and "application/
cose+cbor" media types in the "Media Types" registry.  [CREF26] These
media types are used to indicate that the content is a COSE_MSG.
This section registers the "application/cose" and "application/
cose+cbor" media types in the "Media Types" registry.  [CREF27] These
media types are used to indicate that the content is a COSE_MSG.