Draft: draft-schaad-cose-msg

Commentary: Put in the basic structure plus a couple of algorithm descriptions to get started . Fix travis to be happier when doing a release build .
The COSE_MSG structure is a top level CBOR object which corresponds
to the DataContent type in the Cryptographic Message Syntax
(CMS)RFC5652.  This structure allows for a top level message to be
sent which could be any of the different security services.  The
security service is identified within the message.
The COSE_MSG structure is a top level CBOR object which corresponds
to the DataContent type in the Cryptographic Message Syntax (CMS)
RFC5652.  This structure allows for a top level message to be sent
which could be any of the different security services.  The security
service is identified within the message.
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.
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.
This field is used to ensure that applications will take
appropriate action based on the values found.  This field uses the
integer '2' for the label.  The value is an array of COSE Header
Labels.  The field is used to indicate which protected header
labels an application which is processing a message is required to
understand.
This field is used to ensure that applications will take
appropriate action based on the values found.  The field is used
to indicate which protected header labels an application which is
processing a message is required to understand.  This field uses
the integer '2' for the label.  The value is an array of COSE
Header Labels.  When present, this MUST be placed in the protected
header bucket.
This field one of the ways that can be used to find the key to be
used.  This value can be matched against the 'kid' field in a
COSE_Key structure.  Applications MUST NOT assume that 'kid'
values are unique.  There may be more than one key with the same
'kid' value, it may be required that all of the keys need to be
checked to find the correct one.  This field uses the integer
value of '4' for the label.  The value of field is the CBOR 'bstr'
type.  The internal structure of 'kid' is not defined and
generally cannot be relied on by applications.
This field one of the ways that can be used to find the key to be
used.  This value can be matched against the 'kid' field in a
COSE_Key structure.  Applications MUST NOT assume that 'kid'
values are unique.  There may be more than one key with the same
'kid' value, it may be required that all of the keys need to be
checked to find the correct one.  This field uses the integer
value of '4' for the label.  The value of field is the CBOR 'bstr'
type.  The internal structure of 'kid' is not defined and
generally cannot be relied on by applications.  Key identifier
values are hints about which key to use, they are not directly a
security critical field, for this reason they can normally be
placed in the unprotected headers bucket.
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.
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 and what fields need to be
specified to deal with each of them.
In direct encryption mode, a shared secret between the sender and the
recipient is used as the CEK.  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 'protected', and 'recipients' fields MUST be absent.
This section has moved.  Still need to make some small comments here.
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.  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.  [CREF8]
This document allows for the use of all of the same methods of key
management as are allowed for encryption.
contains the serialized content to be MAC-ed.
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 MAC-ed.  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.
For COSE we use the same set of fields that were defined in RFC7517.
is always bstr encoded rather than tstr encoded.  This change
in encoded is due to the fact that frequently, values such as a
hash of the public key is used for a kid value.  Since the
field is defined as not having a specific structure, making it
binary rather than textual makes sense.
is always bstr encoded rather than tstr encoded.  This change
in encoding is due to the fact that frequently, values such as
a hash of the public key is used for a kid value.  Since the
field is defined as not having a specific structure, making it
binary rather than textual makes sense.
This table contains a list of all of the parameters defined for keys
that were 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.
ECDSA DSS defines a signature algorithm using ECC.
The security strength of the signature is no greater than the minimum
of the security strength associated with the bit length of the key
and the security strength of the hash function.  When a hash function
is used that has greater security than is provided by the length of
the key, the signature algorithm uses the leftmost keyLength bits of
the hash function output.
In order to promote interoperability, it is suggested that SHA-256 be
used only with keys of length 256, SHA-384 be used only with keys of
length 384 and SHA-512 be used only with keys of length 521.  This is
aligned with the recommendation in Section 4 of RFC5480.
The signature algorithm results in a pair of integers (R, S).  These
integers will be of the same order as length of the key used for the
signature process.  The signature is encoded by converting the
integers into byte strings of the same length as the key size.  The
length is rounded up to the nearest byte and is left padded with zero
bits to get to the correct length.  The two integers are then
concatenated together to form a byte string that is the resulting
signature.
On of the issues that needs to be discussed is substitution attacks.
There are two different things that can potentially be substituted in
this algorithm.  Both of these attacks are current theoretical only.
The first substitution attack is changing the curve used to validate
the signature, the only requirement is that the order of the key
match the length of R and S.  It is theoretically possible to use a
different curve and get a different result.  We current do not have
any way to deal with this version of the attack except to restrict
the overall set of curves that can be used.
The second substitution attack is to change the hash function that is
used to verify the signature.  This attack can be mitigated by
including the signature algorithm identifier in the data to be
signed.
MAC algorithms can be based on either a block cipher algorithm (i.e.
AES-MAC) or a hash algorithm (i.e.  HMAC).  This document defines a
MAC algorithm for each of these two constructions.
The Hash-base Message Authentication Code algorithm (HMAC) RFC4231
was designed, in part, to deal with the birthday attacks on straight
hash functions.  The algorithm was also designed to all for new hash
algorithms to be directly plugged in without changes to the hash
function.  The HMAC design process has been vindicated as, while the
security of hash algorithms such as MD5 has decreased over time, the
security of HMAC combined with MD5 has not yet been shown to be
compromised RFC6151.
For use in constrained environments, we define a set of HMAC
algorithms that are truncated.  There are currently no known issues
when truncating, however the security strength of the message tag is
correspondingly reduced in strength.  When truncating, the left most
tag length bits are kept and transmitted.
TBD.
There are a set of different algorithms that we can specify here.
Which should it be?
AES-CMAC - RFC 4493 - has improved security over AES-CBC.  The
padding is different from CBC mode and requires one extra AES
block encryption step plus and xor operation.
Counter with CBC-MAC (CCM) is a generic authentication encryption
block cipher mode defined in RFC3610.  The CCM mode is combined with
the AES block encryption algorithm to define a commonly used content
encryption algorithm used in constrainted devices.
The CCM mode has two parameter choices.  The first choice is M, the
size of the authentication field.  The choice of the value for M
involves a trade-off between message expansion and the probably that
an attacker can undetecably modify a message.  The second choice is
L, the size of the length field.  This value requires a trade-off
between the maximum message size and the size of the Nonce.
It is unfortunate that the specification for CCM specified L and M as
a count of bytes rather than a count of bits.  This leads to possible
misunderstandings where AES-CCM-8 is frequently used to refer to a
version of CCM mode where the size of the authentication is 64-bits
and not 8-bits.  These values have traditionally been specified as
bit counts rather than byte counts.  This document will follow the
tradition of using bit counts so that it is easier to compare the
different algorithms presented in this document.
limits messages to 2^16 bytes in length.  The nonce length is 13
octets allowing for 2^(13*8) possible values of the nonce without
repeating.
limits messages to 2^64 byes in length.  The nonce length is 7
octets allowing for 2^56 possible values of the nonce without
repeating.
produces a 64-bit authentication tag.  This implies that there is
a 1 in 2^64 chance that an modified message will authenticate.
produces a 128-bit authentication tag.  This implies that there is
a 1 in 2^128 chance that an modified message will authenticate.
M00TODO: Make a determination of which ones get 1-, 2- or 3-byte
identifiers.  I.e. which ones are going to be popular.
The key and nonce pair MUST be unique for every message encrypted.
The total number of times the AES block cipher is used MUST NOT
exceed 2^61 operations.  This limitation is the sum of times the
block cipher is used in computing the MAC value and in performing
stream encryption operations.  An explicit check is required only
in environments where it is expected that it might be exceeded.
RFC3610 additionally calls out one other consideration of note.  It
is possible to do a pre-computation attack against the algorithm in
cases where the portions encryption content is highly predictable.
This reduces the security of the key size by half.  Ways to deal with
this attack include adding a random portion to the nonce value and/or
increasing the key size used.  Using a portion of the nonce for a
random value will decrease the number of messages that a single key
can be used for.  Increasing the key size may require more resources
in the constrained device.  See sections 5 and 10 of RFC3610 for more
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 thisdocument to deal with each of
them.
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.
The 'recipients' field is normally absent, but can be used.
Applications MUST deal with a recipients field present, not being
able to decrypt that recipient is an acceptable way of dealing
with it.  Failing to process the message is not an acceptable way
of dealing with it.
This is the value used for the label.  The label can be either an
integer or a string.  Registration in the table is based on the
value of the label requested.  Integer values between 0 and 255
and strings of length 1 are designated as Standards Track Document
required.  Integer values from 256 to 65535 and strings of length
2 are designated as Specification Required.  Integer values of
greater than 65535 and strings of length greater than 2 are
designated as first come first server.  Integer values in the
range -1 to -65536 are delegated to the "COSE Header Algorithm
Label" registry.  Integer values beyond -65536 are marked as
private use.
This is the value used for the label.  The label can be either an
integer or a string.  Registration in the table is based on the
value of the label requested.  Integer values between 1 and 255
and strings of length 1 are designated as Standards Track Document
required.  Integer values from 256 to 65535 and strings of length
2 are designated as Specification Required.  Integer values of
greater than 65535 and strings of length greater than 2 are
designated as first come first server.  Integer values in the
range -1 to -65536 are delegated to the "COSE Header Algorithm
Label" registry.  Integer values beyond -65536 are marked as
private use.
Additionally, the value of 0 is to be marked as 'Reserved'.
The initial contents of the registry can be found in ALG_TABLE.  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.  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.  [CREF9] 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.  [CREF13] These
media types are used to indicate that the content is a COSE_MSG.