Draft: draft-ietf-cose-msg

Commentary: Clean out some crefs that I do n't care about any more Make protected part of the KDF structure . Remove password based algorithms Updates to EC key structures .
The AES Key Wrapping algorithm is defined in RFC3394.  This algorithm
uses an AES key to wrap a value that is a multiple of 64-bits, as
such it can be used to wrap a key for any of the content encryption
algorithms defined in this document.  [CREF10] The algorithm requires
a single fixed parameter, the initial value.  This is fixed to the
value specified in Section 2.2.3.1 of RFC3394.  There are no public
parameters that vary on a per invocation basis.
The AES Key Wrapping algorithm is defined in RFC3394.  This algorithm
uses an AES key to wrap a value that is a multiple of 64-bits, as
such it can be used to wrap a key for any of the content encryption
algorithms defined in this document.  The algorithm requires a single
fixed parameter, the initial value.  This is fixed to the value
specified in Section 2.2.3.1 of RFC3394.  There are no public
parameters that vary on a per invocation basis.
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.[CREF11] Applications can impose additional restrictions on
the length of the modulus.
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.
At a minimum, the 'unprotected' field MUST contain the 'alg'
parameter, a parameter identifying the recipient asymmetric key,
and a parameter with the sender's asymmetric public key.
The 'protected' field is fed into the KDF context structure.
The 'alg' parameter MUST be present in the layer.
A parameter identifying the recipient's key SHOULD be present.  A
parameter identifying the senders key SHOULD be present.
Keys are identified by the 'kty' member of the COSE_Key object.  In
this document we define four values for the member.
Key types are identified by the 'kty' member of the COSE_Key object.
In this document we define four values for the member.
NOTE: This section represents at risk work depending on the ability
to get good references for Curve25519 and Goldilocks.
New versions of ECC have been targeted at variants where only a
single value of the EC Point need to be transmitted.  This work is
currently going on in the IRTF CFRG group.
contains an identifier of the curve to be used with the key.
[CREF14] The curves defined in this document for this key type can
be found in table-ec-curves.  Other curves may be registered in
the future and private curves can be used as well.
One class of Elliptic Curve mathematics allows for a point to be
completely defined using the curve and the x coordinate of the point
on the curve.  The two curves that are initially setup to use is
point format are Curve 25519 and Curve 448 which are defined in I-
D.irtf-cfrg-curves.
contains an identifier of the curve to be used with the key.
[CREF10] The curves defined in this document for this key type can
be found in table-ec-curves.  Other curves may be registered in
the future and private curves can be used as well.
For public keys, it is REQUIRED that 'crv' and 'x' be present in the
structure.  For private keys, it is REQUIRED that 'crv' and 'd' be
present in the structure.  It is RECOMMENDED that 'x' also be
present, but it can be recomputed from the required elements and
omitting it saves on space.
For public keys, it is REQUIRED that 'crv' and 'x' be present in the
structure.  For private keys, it is REQUIRED that 'crv' and 'd' be
present in the structure.  For private keys, it is RECOMMENDED that
'x' also be present, but it can be recomputed from the required
elements and omitting it saves on space.
For public keys, it is REQUIRED that 'crv', 'x' and 'y' be present in
the structure.  For private keys, it is REQUIRED that 'crv' and 'd'
be present in the structure.  It is RECOMMENDED that 'x' and 'y' also
be present, but they can be recomputed from the required elements and
omitting them saves on space.
For public keys, it is REQUIRED that 'crv', 'x' and 'y' be present in
the structure.  For private keys, it is REQUIRED that 'crv' and 'd'
be present in the structure.  For private keys, it is RECOMMENDED
that 'x' and 'y' also be present, but they can be recomputed from the
required elements and omitting them saves on space.
The initial contents of the registry can be found in the following:
table-AES-CCM, table-AES-GCM, table_ecdsa, table-hmac, table-direct,
table_aes_keywrap, table-RSA-OAEP.  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-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.
This section registers the "application/cose" and "application/
cose+cbor" media types in the "Media Types" registry.  [CREF17] 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.  [CREF13] These
media types are used to indicate that the content is a COSE_MSG.