Draft: draft-schaad-cose-msg

Commentary: Do clean up of some text . Expand section on Key Management methods after it got moved for algorithms . Add a new MAC example
There has been an increased focus on the small, constrained devices
that make up the Internet of Things (IOT).  One of the standards that
has come of of this process is the Concise Binary Object
Representation (CBOR).  This standard extends the data model of the
JavaScript Object Notation (JSON) by allowing for binary data among
other changes.  CBOR is being adopted by several of the IETF working
groups dealing with the IOT world to do their encoding of data
structures.  CBOR was designed specifically to be both small in terms
of messages transport and implementation size.  A need exists to
provide basic message security services for IOT and using CBOR as the
message encoding format makes sense.
There has been an increased focus on the small, constrained devices
that make up the Internet of Things (IOT).  One of the standards that
has come of of this process is the Concise Binary Object
Representation (CBOR).  CBOR extended the data model of the
JavaScript Object Notation (JSON) by allowing for binary data among
other changes.  CBOR is being adopted by several of the IETF working
groups dealing with the IOT world as their encoding of data
structures.  CBOR was designed specifically to be both small in terms
of messages transport and implementation size as well having a schema
free decoder.  A need exists to provide basic message security
services for IOT and using CBOR as the message encoding format makes
sense.
NOTE: At some point we need to make some decisions about how we are
using CDDL in this document.  Since this draft has not been moving
forward at a great rate, changing all references on it to
informational is a good idea.  On the other hand, having some type of
syntax that can be examined by a machine to do syntax checking is a
big win.  The build system for this draft is currently using the
latest version of CDDL to check that the syntax of the examples is
correct.  Doing this has found problems in both the syntax checker,
the syntax and the examples.
NOTE[CREF2]: At some point we need to make some decisions about how
we are using CDDL in this document.  Since this draft has not been
moving forward at a great rate, changing all references on it to
informational is a good idea.  On the other hand, having some type of
syntax that can be examined by a machine to do syntax checking is a
big win.  The build system for this draft is currently using the
latest version of CDDL to check that the syntax of the examples is
correct.  Doing this has found problems in both the syntax checker,
the syntax and the examples.
One of the standard issues that is specified in IETF cryptographic
algorithms is a requirement that a standard specify a set of minimal
algorithms that are required to be implemented.  This is done to
promote interoperability as it provides a minimal set of algorithms
that all devices can be sure will exist at both ends.  However, we
have elected not to specify a set of mandatory algorithms in this
document.
Byte is a synonym for octet.
Key management is used as a term to describe how a key at level n is
obtained from level n+1 in encrypted and MACed messages.  The term is
also used to discuss key life cycle management, this document does
not discuss key life cycle operations.
One of the issues that needs to be addressed is a requirement that a
standard specify a set of algorithms that are required to be
implemented.  [CREF3] This is done to promote interoperability as it
provides a minimal set of algorithms that all devices can be sure
will exist at both ends.  However, we have elected not to specify a
set of mandatory algorithms in this document.
Advertising in the message (S/MIME capabilities) RFC5751.
Both buckets are implemented as CBOR maps.  The map key is a 'label'
(label).  The value portion is dependent on the definition for the
label.  Both maps use the same set of label/value pairs.  The integer
range for labels has been divided into several sections with a
standard range, a private range, and a range that is dependent on the
algorithm selected.  The tables of labels can be found in Header-
Table.
contains attributes about the layer that are to be
cryptographically protected.  This bucket MUST NOT be used if it
is not going to be included in a cryptographic computation.
Both buckets are implemented as CBOR maps.  The map key is a 'label'
(label).  The value portion is dependent on the definition for the
label.  Both maps use the same set of label/value pairs.  The integer
range for labels has been divided into several sections with a
standard range, a private range, and a range that is dependent on the
algorithm selected.  The defined labels can be found in the 'COSE
Header Labels' IANA registry (cose-header-key-table.
contains attributes about the layer that are to be
cryptographically protected.  This bucket MUST NOT be used if it
is not going to be included in a cryptographic computation.  This
bucket is encoded in the message as a binary object.  This value
is obtained by CBOR encoding the protected map and wrapping it in
a bstr object.  This wrapping allows for the encoding of the
protected map to be transported with a greater chance that it will
not be altered in transit.  (Badly behaved intermediates could
decode and re-encode, but this will result in a failure to verify
unless the re-encoded byte string is identical to the decoded byte
string.)  This finesses the problem of all parties needing to be
able to do a common connical encoding.
Integer labels in the range -1 to -255 can be omitted as they
are algorithm dependent.  If an application can correctly
process an algorithm, it can be assumed that it will correctly
process all of the parameters associated with that algorithm.
This field is used to indicate the content type of the data in the
payload or ciphertext fields.  The field uses the integer of '3'
for the label.  The value can be either an integer or a string.
[CREF6] Integers are from the XXXXX[CREF7] IANA registry table.
Strings are from the IANA 'mime-content types' registry.
Applications SHOULD provide this field if the content structure is
potentially ambiguous.
This field is used to indicate the content type of the data in the
payload or ciphertext fields.  The field uses the integer of '3'
for the label.  The value can be either an integer or a string.
[CREF8] Integers are from the XXXXX[CREF9] IANA registry table.
Strings are from the IANA 'mime-content types' registry.
Applications SHOULD provide this field if the content structure is
potentially ambiguous.
This field holds either a nonce or Initialization Vector value.
This value can be used either as a counter value for a protocol or
as an IV for an algorithm.  TODO: Talk about zero extending the
value in some cases.
This table contains a list of all of the parameters for use in
signature and encryption message types defined by the JOSE document
set.  In the table is the data value type to be used for CBOR as well
as the integer value that can be used as a replacement for the name
in order to further decrease the size of the sent item.
This table contains a list of all of the generic header parameters
defined in document.  In the table is the data value type to be used
for CBOR as well as the integer value that can be used as a
replacement for the name in order to further decrease the size of the
sent item.
contains attributes about the payload that are to be protected by
the signature.  An example of such an attribute would be the
content type ('cty') attribute.  The content is a CBOR map of
attributes that is encoded to a byte stream.  This field MUST NOT
contain attributes about the signature, even if those attributes
are common across multiple signatures.  The labels in this map are
typically taken from Header-Table.
contains attributes about the payload that are not protected by
the signature.  An example of such an attribute would be the
content type ('cty') attribute.  This field MUST NOT contain
attributes about a signature, even if the attributes are common
across multiple signatures.  The labels in this map are typically
taken from Header-Table.
This section has moved.  Still need to make some small comments here.
The CEK is the same as as the identified previously distributed
symmetric key.
The CEK is encrypted using a previously distributed symmetric key-
encryption 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 elements need to be present
for each of the key management techniques.
In this section we describe the structure and methods to be used when
doing MAC authentication in COSE.  JOSE used a variant of the
signature structure for doing MAC operations and it is restricted to
using a single pre-shared secret to do the authentication.  [CREF9]
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.  JOSE used a variant of the
signature structure for doing MAC operations and it is restricted to
using a single pre-shared secret to do the authentication.  [CREF14]
This document allows for the use of all of the same methods of key
management as are allowed for encryption.
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.  [CREF13]
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 a one time nonce value.  The nonce can either be
implicit from the protocol or carried as a value in the
unprotected headers.  [CREF18]
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.
In direct encryption mode, a shared secret between the sender and the
recipient is used as the key.  [CREF14] 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.  [CREF19] 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.  [CREF15] 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.  [CREF20] 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.[CREF16] 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.[CREF21] Applications can impose additional restrictions on
the length of the modulus.
contains an identifier of the curve to be used with the key.
[CREF21] 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.
[CREF26] 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.
Additionally, the value of 0 is to be marked as 'Reserved'.
Additionally, the label of 0 is to be marked as 'Reserved'.
This section registers the "application/cose" and "application/
cose+cbor" media types in the "Media Types" registry.  [CREF25] 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.  [CREF30] These
media types are used to indicate that the content is a COSE_MSG.