Draft: draft-ietf-cose-msg

Commentary: Remove the phrase key management from the draft Close cose - wg / cose - issues
Key management has been made to be more uniform.  All key
management techniques are represented as a recipient rather than
only have some of them be so.
MAC messages have the ability to do key management on the MAC
authentication key.
Recipient processing has been made more uniform.  A recipient
structure is required for all recipients rather than only for
some.
MAC messages have the ability to do use all recipient algorithms
on the MAC authentication key.
In this section we describe the structure and methods to be used when
doing an encryption in COSE.  In COSE, we use the same techniques and
structures for encrypting both the plain text and the keys used to
protect the text.  This is different from the approach used by both
RFC5652 and RFC7516 where different structures are used for the plain
text and for the different key management techniques.
The encryption structure allows for one or more recipients of a
message.  There are provisions for parameters about the content and
parameters about the recipient information to be carried in the
message.  The parameters associated with the content can be
authenticated by the content encryption algorithm.  The parameters
associated with the recipient can be authenticated by the recipient
algorithm (when the algorithm supports it).  Examples of parameters
about the content are the type of the content, when the content was
created, and the content encryption algorithm.  Examples of
parameters about the recipient are the recipients key identifier, the
recipient encryption algorithm.
In COSE, the same techniques and structures for encrypting both the
plain text and the keys used to protect the text.  This is different
from the approach used by both RFC5652 and RFC7516 where different
structures are used for the content layer and for the recipient
layer.
The CEK is the same as as the identified previously distributed
symmetric key.
the recipient's public key and a sender's private key are used to
generate a pairwise symmetric key, then the CEK is either the
derived key or encrypted by the derived key.
the CEK is encrypted in a key-encryption key that is derived from
a password or other shared secret value.
key-management-algs provides details on a number of different key
management algorithms and discusses which parameters need to be
present for each of the key management techniques.
The CEK is the same as as the identified previously distributed
symmetric key or derived from a previously distributed secret.
the recipient's public key and a sender's private key are used to
generate a pairwise secret, a KDF is applied to derive a key, and
then the CEK is either the derived key or encrypted by the derived
key.
the CEK is encrypted in a key-encryption key that is derived from
a password.
In this section we describe the structure and methods to be used when
doing MAC authentication in COSE.  This document allows for the use
of all of the same methods of key management as are allowed for
encryption.
In this section we describe the structure and methods to be used when
doing MAC authentication in COSE.  This document allows for the use
of all of the same classes of recipient algorithms as are allowed for
encryption.
For some key management methods, the length of the key is known or
determinable from the key management method.  For example, if RSA-
OAEP is used then the key will be output at the correct length.
However, if any of the key derivation methods are used, then the size
of the key to be obtained is an input parameter to the key derivation
step.  For all HMAC methods defined in this document, the key size
for a key derivation methods MUST be the same size as the hash
function used.  It is RECOMMENDED that the key size be the same size
as the hash function for all other key management methods.
Some recipient algorithms carry the key while others derive a key
from secret data.  For those algorithms which carry the key (i.e.
RSA-OAEP and AES-KeyWrap), the size of the HMAC key SHOULD be the
same size as the underlying hash function.  For those algorithms
which derive the key, the derived key MUST be the same size as the
underlying hash function.
This field contains the protected parameter field.
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 names of the key management methods used here are the same as are
defined in RFC7517.  Other specifications use different terms for the
key management methods or do not support some of the key management
methods.
At the moment we do not have any key management methods that allow
for the use of protected headers.  This may be changed in the future
if, for example, the AES-GCM Key wrap method defined in RFC7518 were
extended to allow for authenticated data.  In that event, the use of
the 'protected' field, which is current forbidden below, would be
permitted.
In direct encryption mode, a shared secret between the sender and the
recipient is used as the key.  When direct encryption mode is used,
it MUST be the only mode used on the message.  It is a massive
security leak to have both direct encryption and a different key
management mode on the same message.
For JOSE, direct encryption key management is the only key management
method allowed for doing MACed messages.  In COSE, all of the key
management methods can be used for MACed messages.
The 'protected', 'ciphertext' and 'recipients' fields MUST be
absent.
At a minimum, the 'unprotected' field MUST contain the 'alg'
parameter and SHOULD contain a parameter identifying the shared
secret.
This key management technique is the simplest method, the supplied
key is directly used as the key for the next layer down in the
message.  There are no algorithm parameters defined for this key
management methods.  The algorithm identifier assignment can be found
in table-direct.
Recipient algorithms can be defined into a number of different
classes.  COSE has the ability to support many classes of recipient
algorithms.  In this section, a number of classes are listed and then
a set of algorithms are specified for each of the classes.  The names
of the recipient algorithm classes used here are the same as are
defined in RFC7517.  Other specifications use different terms for the
recipient algorithm classes or do not support some of our recipient
algorithm classes.
The direct encryption class algorithms share a secret between the
sender and the recipient that is used either directly or after
manipulation as the content key.  When direct encryption mode is
used, it MUST be the only mode used on the message.
The 'protected' field MUST be a zero length item if it is not used
in the computation of the content key.
The 'alg' parameter MUST be present.
A parameter identifying the shared secret SHOULD be present.
The 'ciphertext' field MUST be a zero length item.
The 'recipients' field MUST be absent.
This recipient algorithm is the simplest, the supplied key is
directly used as the key for the next layer down in the message.
There are no algorithm parameters defined for this algorithm.  The
algorithm identifier value is assigned in table-direct.
When this algorithm is used, the protected field MUST be zero length.
This key managment takes a common shared secret between the two
parties and applies the HKDF function (HKDF) using the context
structure defined in context to transform the shared secret into the
necessary key.  Either the 'salt' parameter of HKDF or the partyU
'nonce' parameter of the context structure MUST be present.  This
parameter can be generated either randomly or deterministically, the
requirement is that it be a unique value for the key pair in
question.
These recipient algorithms take a common shared secret between the
two parties and applies the HKDF function (HKDF) using the context
structure defined in context to transform the shared secret into the
necessary key.  Either the 'salt' parameter of HKDF or the partyU
'nonce' parameter of the context structure MUST be present.  This
parameter can be generated either randomly or deterministically, the
requirement is that it be a unique value for the key pair in
question.
If the salt/nonce value is generated randomly, then it is suggested
that the length of the random value be the same length as the hash
function underlying HKDF, i.e 256-bits.  While there is no way to
guarantee that it will be unique, there is a high probability that it
will be unique.  If the salt/nonce value is generated
deterministically, it can be guaranteed to be unique and thus there
is no length requirement.
Since with this technique a new key can be generated for every
message, the restrictions on IVs can frequently be relaxed.  For the
content encryption algorithms used in this document IVs must be
unique for a specific key.  If the key is altered then the IV can be
re-used.  Alternatively, an application can be the IV be generated
from the same context as the key is by changing the algorithm
identifier to the string "IV-GENERATION".
If the salt/nonce value is generated randomly, then it is suggested
that the length of the random value be the same length as the hash
function underlying HKDF.  While there is no way to guarantee that it
will be unique, there is a high probability that it will be unique.
If the salt/nonce value is generated deterministically, it can be
guaranteed to be unique and thus there is no length requirement.
A new IV must be used if the same key is used in more than one
message.  The IV can be modified in a predictable manner, a random
manner or an unpredictable manner.  One unpredictable manner than can
be used is to use the HKDF function to generate the IV.  If HKDF is
used for generating the IV, the algorithm identifier is set to "IV-
GENERATION".
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.  [CREF11] 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.  [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.
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.[CREF12] Applications can impose additional restrictions on
the length of the modulus.
When using the 'Direct Key Agreement' key managment method, the two
parties use a key agreement method to create a shared secret.  A KDF
is then applied to the shared secret to derive a key to be used in
protecting the data.  This key is normally used as a CEK or MAC key,
but could be used for other purposes if more than two layers are in
use (see three-layer).
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.
The 'direct key agreement' class of recipient algorithms uses a key
agreement method to create a shared secret.  A KDF is then applied to
the shared secret to derive a key to be used in protecting the data.
This key is normally used as a CEK or MAC key, but could be used for
other purposes if more than two layers are in use (see three-layer).
When direct key agreement mode is used, it MUST be the only key
management mode used on the message and there MUST be only one
recipient.  This method creates the key directly and that makes it
difficult to mix with additional recipients.  If multiple recipients
are needed, then the version with key wrap needs to be used.
When direct key agreement mode is used, there MUST be only one
recipient in the message.  This method creates the key directly and
that makes it difficult to mix with additional recipients.  If
multiple recipients are needed, then the version with key wrap needs
to be used.
contains an identifier of the curve to be used with the key.
[CREF15] 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.
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.
This section registers the "application/cose" and "application/
cose+cbor" media types in the "Media Types" registry.  [CREF18] 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.  [CREF17] These
media types are used to indicate that the content is a COSE_MSG.