Draft: draft-schaad-cose-msg

Commentary: Add more text for KDF and ECDH . Ignore a couple of more files to make my life easier . Pickup some bug fixes from
contains the serialized content to be signed.
If the payload is not present in the message, the application is
required to supply the payload separately.
The payload is wrapped in a bstr to ensure that it is transported
without changes, if the payload is transported separately it is
the responsibility of the application to ensure that it will be
transported without changes.
contains the serialized content to be signed.  If the payload is
not present in the message, the application is required to supply
the payload separately.  The payload is wrapped in a bstr to
ensure that it is transported without changes, if the payload is
transported separately it is the responsibility of the application
to ensure that it will be transported without changes.
The encryption algorithm for AEAD algorithms is fairly simple.
In order to get a consistent encoding of the data to be
authenticated, the Enc_structure is used to have canonical form of
the AAD.
The encryption algorithm for AEAD algorithms is fairly simple.  In
order to get a consistent encoding of the data to be authenticated,
the Enc_structure is used to have canonical form of the AAD.
The element "kty" is a required element in a COSE_Key map.
All other elements are optional and not all of the elements listed in
RFC7517 or RFC7518 have been listed here even though they can all
appear in a COSE_Key map.
The element "kty" is a required element in a COSE_Key map.  All other
elements are optional and not all of the elements listed in RFC7517
or RFC7518 have been listed here even though they can all appear in a
COSE_Key map.
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.
salt - an optional public value that is used to change the
generation process.  If specified, the salt is carried using the
'salt' algorithm parameter.  While RFC5869 suggests that the
length of the salt be the same as the length of the underlying
hash value, any amount of salt will improve the security as
different key values will be generated.  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.
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.
The context information structure is used to ensure that the derived
keying material is "bound" to the context of the transaction.  The
context information structure used here is based on that defined in
SP800-56A.  By using CBOR for the encoding of the context information
structure, we automatically get the same type of type and length
separation of fields that is obtained by the use of ASN.1.  This
means that there is no need to encode the lengths for the base
elements as it is done by the CBOR encoding.
The context information structure refers to PartyU and PartyV as the
two parties which are doing the key derivation.  Unless the
application protocol defines differently, we assign PartyU to the
entity that is creating the message and PartyV to the entity that is
receiving the message.  This is because we are assuming a set of
stand alone store and forward messaging processes.
Application protocols are free to define the roles differently.  For
example, they could assign the PartyU role to the entity that
initiates the connection and allow directly sending multiple messages
over the line without changing the role information.
This contains the identity information for party U.  The
identities can be assigned in one of two manners.  Firstly, a
protocol can assign identities based on roles.  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 assign identities is to use a
name based on a naming system (i.e.  DNS, X.509 names).
We define an algorithm parameter 'PartyU identity' that can be
used to carry identity information in the message.  However,
identity information is often known as part of the protocol and
can thus be inferred rather than made explicit.  If identity
information is carried in the message, applications SHOULD have
a way of validating the supplied identity information.  The
identity information does not need to be specified and can be
left as absent.
The identity value supplied will be validated as part of the
key derivation process.  If the identity string is wrong, then
the wrong key will be created.
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.  [CREF12]
We define an algorithm parameter 'PartyU nonce' that can be
used to carry this value in the message However, the nonce
value could be determined by the application and the value
determined from elsewhere.
This item is optional and can be absent.
This contains other information that is defined by the
protocol.
This item is optional and can be absent.
M00TODO: Copy down from PartyUInfo when that text is ready.
This field contains public information that is mutually known to
both parties.
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 is
optional and will only be present if the application defines a
structure for this information.  Applications that define this
SHOULD use CBOR to encode the data so that types and lengths
are correctly include.
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.  Applications that define this SHOULD use CBOR to
encode the data so that types and lengths are correctly include.
In direct encryption mode, a shared secret between the sender and the
recipient is used as the key.  [CREF11] 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.
In direct encryption mode, a shared secret between the sender and the
recipient is used as the key.  [CREF13] 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.
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.
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.  [CREF14] 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.[CREF13] 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.[CREF15] Applications can impose additional restrictions on
the length of the modulus.
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.
The 'protected' field MUST be absent if the key wrap algorithm is
an AE algorithm.
Set key type 'kty' to 'EC1'.
Set key type 'kty' to 'EC2'.
The COSE_Key object defines a way to hold a single key object, it is
still required that the members of individual key types be defined.
This section of the document is where we define an initial set of
members for specific key types.
For each of the key types, we define both public and private members.
The public members are what is transmitted to others for their usage.
We define private members mainly for the purpose of archival of keys
by individuals.  However, there are some circumstances where private
keys may be distributed by various entities in a protocol.  Examples
include: Entities which have poor random number generation.
Centralized key creation for multi-cast type operations.  Protocols
where a shared secret is used as a bearer token for authorization
purposes.
Keys are identified by the 'kty' member of the COSE_Key object.  In
this document we define four values for the member.
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.
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.
[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.
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.
The traditional way of sending EC curves has been to send either both
the x and y coordinates, or the x coordinate and a sign bit for the y
coordinate.  The latter encoding has not been recommend in the IETF
due to potential IPR issues with Certicom.  However, for operations
in constrained environments, the ability to shrink a message by not
sending the y coordinate is potentially useful.
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.
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.
Occasionally it is required that a symmetric key be transported
between entities.  This key structure allows for that to happen.
contains the value of the key.
This key structure contains only private key information, care must
be taken that it is never transmitted accidentally.  For public keys,
there are no required fields.  For private keys, it is REQUIRED that
'k' be present in the structure.
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.
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/jwk+json" and "application/
jwk-set+json" media typesin the "Media Types" registry.  These media
types are used to indicate, respectively, that content is a COSE_Key
or COSE_KeySet object.
This section registers the "application/cose+json" and "application/
cose-set+json" media typesin the "Media Types" registry.  These media
types are used to indicate, respectively, that content is a COSE_Key
or COSE_KeySet object.