Draft: draft-ietf-cose-msg

Commentary: Respond to mailed in comments .
MAC messages are separated from signed messages.
MAC messages have the ability to use the same set of recipient
algorithms as enveloped messages for obtaining the MAC
authentication key.
MACed messages are separated from signed messages.
MACed messages have the ability to use the same set of recipient
algorithms as enveloped messages for obtaining the MAC
authentication key.
The presence of a label in a map that is not a string or an integer
is an error.  Applications can either fail processing or process
messages with incorrect labels, however they MUST NOT create messages
with incorrect labels.
The presence of a label in a COSE map which is not a string or an
integer is an error.  Applications can either fail processing or
process messages with incorrect labels, however they MUST NOT create
messages with incorrect labels.
Authenticated Encryption (AE) algorithms are those encryption
algorithms which provide an authentication check of the contents
algorithm with the encryption service.
Authenticated Encryption with Authenticated Data (AEAD) algorithms
provide the same content authentication service as AE algorithms, but
additionally provide for authentication of non-encrypted data as
well.
The message type is identified by a CBOR tag.  This document
defines a CBOR tag for each of the message structures.  These tags
can be found in CBOR-Tags.
The message type is identified by a CBOR tag.  Messages with a
CBOR tag are known in this specification as tagged messages, while
those without the CBOR tag are known as untagged messages.  This
document defines a CBOR tag for each of the message structures.
These tags can be found in CBOR-Tags.
Contains parameters about the current layer that are to be
cryptographically protected.  This bucket MUST be empty 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.  Senders SHOULD encode an empty protected map as a
zero length binary object (it is both shorter and the version used
in the authentication structures).  Recipients MUST accept both a
zero length binary value and a zero length map encoded in the
binary value.  The 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 canonical encoding.
Contains parameters about the current layer that are to be
cryptographically protected.  This bucket MUST be empty 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.  Senders SHOULD encode an empty protected map as a
zero length binary object (i.e., the byte string h'a0').  This
encoding is used because it is both shorter and the version used
in the serialization structures for cryptographic computation.
Recipients MUST accept both a zero length binary value and a zero
length map encoded in the binary value.  The 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 avoids the problem of all
parties needing to be able to do a common canonical encoding.
Labels in each of the maps MUST be unique.  When processing messages,
if a label appears multiple times, the message MUST be rejected as
malformed.  Applications SHOULD perform the same checks that the
labels appearing in the protected and unprotected headers are unique
as well.  If the message is not rejected as malformed, attributes
MUST be obtained from the protected bucket before they are obtained
from the unprotected bucket.
Labels in each of the maps MUST be unique.  When processing messages,
if a label appears multiple times, the message MUST be rejected as
malformed.  Applications SHOULD perform the same checks that the same
label does not occur in both the protected and unprotected headers.
If the message is not rejected as malformed, attributes MUST be
obtained from the protected bucket before they are obtained from the
unprotected bucket.
This parameter is used to indicate the content type of the data in
the payload or cipher text fields.  Integers are from the "CoAP
Content-Formats" IANA registry table.  Strings are from the IANA
"Media Types" registry.  Applications SHOULD provide this
parameter if the content structure is potentially ambiguous.
This parameter is used to indicate the content type of the data in
the payload or cipher text fields.  Integers are from the "CoAP
Content-Formats" IANA registry table.  Text values following the
syntax of Content-Type defined in Section 5.1 of RFC2045 omitting
the prefix string "Content-Type:".  Leading and trailing
whitespace is also omitted.  Textual content values along with
parameters and subparameters can be located using the IANA "Media
Types" registry.  Applications SHOULD provide this parameter if
the content structure is potentially ambiguous.
This parameter holds one or more counter signature values.
Counter signatures provide a method of having a second party sign
some data.  The counter signature can occur as an unprotected
attribute in any of the following structures: COSE_Sign,
COSE_Sign1, COSE_Signature, COSE_Encrypt, COSE_recipient,
COSE_Encrypt1, COSE_Mac and COSE_Mac0.  These structures all have
the same beginning elements so that a consistent calculation of
the counter signature can be computed.  Details on computing
counter signatures are found in counter_signature.
This parameter holds one or more counter signature values.
Counter signatures provide a method of having a second party sign
some data.  The counter signature can occur as an unprotected
attribute in any of the following structures: COSE_Sign,
COSE_Sign1, COSE_Signature, COSE_Encrypt, COSE_recipient,
COSE_Encrypt0, COSE_Mac and COSE_Mac0.  These structures all have
the same beginning elements so that a consistent calculation of
the counter signature can be computed.  Details on computing
counter signatures are found in counter_signature.
COSE supports two different signature structures.  COSE_Sign allows
for one or more signers to be applied to a single content.
COSE_Sign1 is restricted to a single signer.  The structures cannot
be converted between each other; the signature computation includes a
parameter identifying which structure is being used.
COSE supports two different signature structures.  COSE_Sign allows
for one or more signers to be applied to a single content.
COSE_Sign1 is restricted to a single signer.  The structures cannot
be converted between each other; as the signature computation
includes a parameter identifying which structure is being used, the
converted structure will fail signature validation.
The CBOR object that carries the body, the signature, and the
information about the body and signature is called the COSE_Sign1
structure.  Examples of COSE Single signature messages can be found
in Sign1_Examples.
The CBOR object that carries the body, the signature, and the
information about the body and signature is called the COSE_Sign1
structure.  Examples of COSE_Sign1 messages can be found in
Sign1_Examples.
COSE supports two different encryption structures.  COSE_Encrypt1 is
used when a recipient structure is not needed because the key to be
used is known implicitly.  COSE_Encrypt is used the rest of the time.
This includes cases where there are multiple recipients or a
recipient algorithm other than direct is used.
COSE supports two different encryption structures.  COSE_Encrypt0 is
used when a recipient structure is not needed because the key to be
used is known implicitly.  COSE_Encrypt is used the rest of the time.
This includes cases where there are multiple recipients or a
recipient algorithm other than direct is used.
The COSE_Encrypt1 encrypted structure does not have the ability to
specify recipients of the message.  The structure assumes that the
recipient of the object will already know the identity of the key to
be used in order to decrypt the message.  If a key needs to be
identified to the recipient, the enveloped structure ought to be
used.
The COSE_Encrypt0 encrypted structure does not have the ability to
specify recipients of the message.  The structure assumes that the
recipient of the object will already know the identity of the key to
be used in order to decrypt the message.  If a key needs to be
identified to the recipient, the enveloped structure ought to be
used.
for the content encryption of a COSE_Encrypt1 data structure.
for the content encryption of a COSE_Encrypt0 data structure.
for a recipient encoding to be placed in a MAC message
structure.
for a recipient encoding to be placed in a MACed message
structure.
The multiple recipient MAC message uses two structures, the COSE_Mac
structure defined in this section for carrying the body and the
COSE_recipient structure (EnvelopedData) to hold the key used for the
MAC computation.  Examples of MAC messages can be found in
MacExamples.
The multiple recipient MACed message uses two structures, the
COSE_Mac structure defined in this section for carrying the body and
the COSE_recipient structure (EnvelopedData) to hold the key used for
the MAC computation.  Examples of MACed messages can be found in
MacExamples.
The MAC message uses the COSE_Mac0 structure defined in this section
for carrying the body.  Examples of MAC messages with an implicit key
can be found in Mac0Examples.
The MACed message uses the COSE_Mac0 structure defined in this
section for carrying the body.  Examples of MACed messages with an
implicit key can be found in Mac0Examples.
The Hash-base Message Authentication Code algorithm (HMAC) RFC4231
was designed to deal with length extension attacks.  The algorithm
was also designed to allow 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.
The Hash-base Message Authentication Code algorithm (HMAC) RFC4231
was designed to deal with length extension attacks.  The algorithm
was also designed to allow for new hash algorithms to be directly
plugged in without changes to the hash function.  The HMAC design
process has been shown as solid since, 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.
These algorithms are used in COSE_Encrypt and COSE_Encrypt1.
These algorithms are used in COSE_Encrypt and COSE_Encrypt0.
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.
RFC3610 additionally calls out one other consideration of note.  It
is possible to do a pre-computation attack against the algorithm in
cases where portions of the plaintext are 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.
See description of PartyUInfo identity.
See description of PartyUInfo nonce.
See description of PartyUInfo other.
This field holds information about party V.  The content of the
structure are the same as for the PartyUInfo but for partyV.
If the 'alg' is field present, it MUST match the AES Key Wrap
algorithm being used.
If the 'alg' field is present, it MUST match the AES Key Wrap
algorithm being used.
It is requested that IANA assign the following tags from the "Concise
Binary Object Representation (CBOR) Tags" registry.  It is requested
that the tags for COSE_Sign1, COSE_Encrypt1 and COSE_Mac0 be assigned
in the 1 to 23 value range (i.e., one byte long when encoded).  It is
requested that the rest of the tags be assigned in the 24 to 255
value range (i.e., two bytes long when encoded).
It is requested that IANA assign the following tags from the "Concise
Binary Object Representation (CBOR) Tags" registry.  It is requested
that the tags for COSE_Sign1, COSE_Encrypt0, and COSE_Mac0 be
assigned in the 1 to 23 value range (one byte long when encoded).  It
is requested that the rest of the tags be assigned in the 24 to 255
value range (two bytes long when encoded).
NOTE: The assignment of algorithm identifiers in this document was
done so that positive numbers were used for the first layer objects
(COSE_Sign, COSE_Sign1, COSE_Encrypt, COSE_Encrypt1, COSE_Mac and
COSE_Mac0).  Negative numbers were used for second layer objects
(COSE_Signature and COSE_recipient).  Expert reviewers should
consider this practice, but are not expected to be restricted by this
precedent.
NOTE: The assignment of algorithm identifiers in this document was
done so that positive numbers were used for the first layer objects
(COSE_Sign, COSE_Sign1, COSE_Encrypt, COSE_Encrypt0, COSE_Mac, and
COSE_Mac0).  Negative numbers were used for second layer objects
(COSE_Signature and COSE_recipient).  Expert reviewers should
consider this practice, but are not expected to be restricted by this
precedent.