Draft: draft-schaad-cose-msg

Commentary: Edit the readme to reflect that the COSE group exists Add a note for contributions with some instructions Expand some more algorithms Add structure for keys
The source for this draft is being maintained in GitHub.  Suggested
changes should be submitted as pull requests at https://github.com/
cose-wg/cose-spec.  Instructions are on that page as well.  Editorial
changes can be managed in GitHub, but any substantial issues need to
be discussed on the COSE mailing list.
There are a number of different key management methods that can be
used in the COSE encryption system.  In this section we will discuss
each of the key management methods, what fields need to be specified,
and which algorithms are defined in thisdocument to deal with each of
them.
See RFC5869.
secret - a shared value that is secret.  Secrets may be either
previously shared or derived from operations like a DH key
agreement.
salt - an optional public value that is used to change the
generation process.  If specified, the salt is carried using the
'salt' algorithm parameter.  The 'salt' parameter is encoded as a
binary string.  This parameter is protected by being included in
the key computation and does not need to be separately
authenticated.
length - the number of octets of output that need to be generated.
hash function - The underlying hash function to be used in the
HKDF algorithm.  The hash function is encoded into the HKDF
algorithm selection.
This is set to the number of bits of the desired output value.
This field indicates how the key material will be used.  Unless
key material is being derived for multiple items (i.e both a key
and an IV) this will be the COSE algorithm value.
This contains the identity information for party U.  The
identity information can be specified in one of two manners.
The protocol can define a role based identity value.  For
example, the roles of "client" and "server" may be assigned to
different entities in the protocol.  Each entity would then use
the correct label for the data they they send or receive.  The
second way is for a protocol to define a way for identification
tags to be used based on a naming system (i.e.  DNS, X.509
names).
This contains a one time nonce value.  The nonce can either be
implicit from the protocol or carried as a value in the
unprotected headers.
This contains other information that is defined as the
protocol.
Copy down from PartyUInfo when that text is ready.
The size of the output in bits is placed in keyDataLength.  The
field other is for free form data defined by the application.  An
example is that an application could defined two different strings
to be placed here to generate different keys for a data stream vs
a control stream.
This field contains private information that is mutually known
information.  An example of this information would be a pre-
existing shared secret.  The field is optional and will only be
present if the application defines a structure for this
information.
There are a number of different key management methods that can be
used in the COSE encryption system.  In this section we will discuss
each of the key management methods, what fields need to be specified,
and which algorithms are defined in this document to deal with each
of them.
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.  [CREF12] 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.
There are no specific security considerations for this algorithm.
Direct Key Agreement derives the CEK from the shared secret computed
by the key agreement operation.
When direct key agreement mode is used, it SHOULD be the only mode
used on the message.  This method creates the CEK directly and that
makes it difficult to mix with additional recipients.
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.
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.[CREF13] Applications can impose additional restrictions on
the length of the modulus.
Direct Key Agreement derives a key from the shared secret computed by
the key agreement operation.
When direct key agreement mode is used, it SHOULD be the only mode
used on the message.  This method creates the key directly and that
makes it difficult to mix with additional recipients.
At a minimum, the 'unprotected' field MUST contain the 'alg'
parameter and SHOULD contain a parameter identifying the
asymmetric key.
At a minimum, the 'unprotected' field MUST contain the 'alg'
parameter and SHOULD contain a parameter identifying the
recipient's asymmetric key.
Set key type 'kty' to 'EC1'.
Set key type 'kty' to 'EC2'.
The initial contents of the registry can be found in the following:
table-AES-CCM, table-AES-GCM, table_ecdsa, table-hmac.  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_ecdsa, table-hmac, table-direct,
table_aes_keywrap, table-RSA-OAEP.  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.  [CREF13] 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.  [CREF16] These
media types are used to indicate that the content is a COSE_MSG.