Draft: draft-schaad-cose-msg

Commentary: Expand text on HKDF and context Expand text on ECDH direct -still need to do
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.
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.
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.
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.
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).
The most commonly used key agreement algorithm used is Diffie-
Hellman, but other variants exist.  Since COSE is designed for a
store and forward environment rather than an on-line environment,
many of the DH variants cannot be used as the receiver of the message
cannot provide any key material.  One side-effect of this is that
perfect forward security is not achievable, a static key will always
be used for the receiver of the COSE message.
Ephemeral-Static DH: where the sender of the message creates a one
time DH key and uses a static key for the recipient.  The use of
the ephemeral sender key means that no additional random input is
needed as this is randomly generated for each message.
In this specification, both variants are specified.  This has been
done to provide the weak data origination option for use with MAC
operations.
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 (ECDH-KeyWrap) needs to be
used.
This algorithm uses the key agreement algorithm specified in RFC6090
combined with the KDF defined in HKDF to generate the key to be used
in encrypting/decrypting the next layer down.
NOTE: Curves 25519 and Goldilocks are elements at risk.
We setup to use two different curve structures for the ECDH
algorithms.
Weierstrass Curves: These are the ones one is used to seeing from
NIST.  We define three NIST curves for use with this document.
These curves are P-256, P-384 and P-512.  (The mathematics can be
found in RFC6090.)  For these curves, the key type 'EC2' is used
(EC2-Keys).
Montgomery Curves: These curves are Curve25519 and Goldilocks.
(The mathematics can be found in I-D.irtf-cfrg-curves.)  For these
curves, the key type 'EC1' is used (EC1-Keys).
This parameter is used to hold and transport the ephemeral key
generated by the sender of the message.  This parameter has a
label of -1 and a type of COSE_Key.  This parameter can be
placed in the unprotected bucket, if it is changed then the
correct key will not be able to be generated.
The parameter is summarized in table-ecdh-es-parameter-table.
This parameter is used to hold and transport the static key
used by the sender of the message.  This parameter has the
label of -2 and a type of COSE_Key.  The parameter can be
placed in the unprotected bucket, if it is changed then the
correct key will not be able to be generated.  If the data
origination service is desired, then the message recipient
needs to validate that the key in this field is associated with
the sender.
This parameter is used to hold a reference to the static key
used by the sender of the message.  The value is expected to
match the 'kid' member of a COSE_Key structure published by the
sender.  The value in this field cannot be assumed to uniquely
identify a single key, multiple keys may need to be found and
tested.  Not all of the keys identified by a kid value may be
associated with the sender of the message.  If the data
origination service is desired, then the message recipient
needs to validate that the key in this field is associated with
the sender.
These parameters are summarized in table-ecdh-es-parameter-table.
M00TODO: Talk about curves and point formats.
Two different key structures are being defined for Elliptic Curve
keys.  One version uses both an x and a y coordinate, potentially
with point compression.  This is the traditional EC point
representation that is used in [EC-in-PKIX].  The other version uses
only the x coordinate as the y coordinate is either to be recomputed
or not needed for the key agreement operation.  An example of this is
[Curve25549].
NOTE: This section represents at risk work depending on the ability
to get good references for Curve24559 and Goldilocks.
Two different key structures are being defined for Elliptic Curve
keys.  One version uses both an x and a y coordinate, potentially
with point compression.  This is the traditional EC point
representation that is used in [EC-in-PKIX].  The other version uses
only the x coordinate as the y coordinate is either to be recomputed
or not needed for the key agreement operation.  An example of this is
[Curve25519].
NOTE: This section represents at risk work depending on the ability
to get good references for Curve25519 and Goldilocks.
contains an identifier of the curve to be used with the key.
[CREF18] The curves defined in this document for this key type can
be found in table-ec1-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.
[CREF20] 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.  The
curves defined in this document for this key type can be found in
table-ec2-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.  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.  [CREF22] 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.  [CREF24] These
media types are used to indicate that the content is a COSE_MSG.