Draft: draft-ietf-cose-msg

Commentary: Some more edits in response to the review . Does not include one item that was proposed for clarification
COSE messages are also built using the concept of using layers to
separate different types of cryptographic concepts.  As an example of
how this works consider the COSE_Encrypt message (EnvelopedData).
This message type is broken into two layers: the content layer and
the recipient layer.  In the content layer, the plain text is
encrypted and information about the encrypted message are placed.  In
the recipient layer, the content encryption key (CEK) is encrypted
and information about how it is encrypted for each recipient is
placed.  A single layer version of the encryption message
COSE_Encrypt0 (EnvelopedData0) is provided for cases where the CEK is
pre-shared.
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.
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 zero length map as a zero
length string rather than as a zero length map (encoded as h'a0').
The zero length binary encoding is preferred because it is both
shorter and the version used in the serialization structures for
cryptographic computation.  After encoding the map the value is
wrapped in the binary object.  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.
Integer labels in the range -1 to -128 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 common parameters associated with that
algorithm.  Integer labels in the range -129 to -65536 SHOULD
be included as these would be less common parameters that might
not be generally supported.
security critical field.  For this reason, it SHOULD be placed in
the unprotected headers bucket.
This parameter holds the Initialization Vector (IV) value.  For
some symmetric encryption algorithms this may be referred to as a
nonce.  As the IV is authenticated by the encryption process, it
SHOULD be placed in the unprotected header bucket.
security critical field.  For this reason, it can be placed in the
unprotected headers bucket.
This parameter holds the Initialization Vector (IV) value.  For
some symmetric encryption algorithms this may be referred to as a
nonce.  As the IV is authenticated by the encryption process, it
can be placed in the unprotected header bucket.
contains the encrypted key encoded as a bstr.  If there is not an
encrypted key, then this field is encoded as a nil value.
contains the encrypted key encoded as a bstr.  All encoded keys
are symetric keys, the binary value of the key is the content.  If
there is not an encrypted key, then this field is encoded as a nil
value.