Draft: draft-schaad-cose

Commentary: Match the updated grammar for CDDL Move parameters from in the text to an appendix . Add description for MAC object
contains the top level fields for the security service provided.
The type in this field is based on the value of the field
msg_type.
contains attributes about the payload which 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 which is encoded to a byte stream.  This field MUST NOT
contain attributes about the signature, even if those attributes
are common across multiple signatures.  At least one of protected
and unprotected MUST be present.
contains attributes about the payload which 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.  At least one of protected and
unprotected MUST be present.
contains attributes about the payload which 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 which is encoded to a byte stream.  This field MUST NOT
contain attributes about the signature, even if those attributes
are common across multiple signatures.
contains attributes about the payload which 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.
Comput the hash value from the byte string.
In this section we describe the structure and methods to be used when
doing an encryption in COSE.  In COSE, we use the same techniques and
structures for encrypting both the plain text and the keys used to
protect the text.  This is different from the approach used by both
RFC5652 and I-D.ietf-jose-json-web-encryption where different
structures are used both for the plain text and for the different key
management techniques.
In this section we describe the structure and methods to be used when
doing an encryption in COSE.  In COSE, we use the same techniques and
structures for encrypting both the plain text and the keys used to
protect the text.  This is different from the approach used by both
RFC5652 and I-D.ietf-jose-json-web-encryption where different
structures are used for the plain text and for the different key
management techniques.
A single COSE_Element, encoded as an extension to the containing
COSE_element, for a single recipient.  Single recipients can be
encoded either this way or as a single array element.
The header parameters discussed here are taken from I-D.ietf-jose-
json-web-encryption.  For the most part they are interpreted the same
here as for JOSE.
contains the algorithm identifier used to encrypt the plain text.
contains an ephemeral key for key agreement management algorithms.
Note however, that it is a COSE encoded key and not a JOSE encoded
key.
contains a compression algorithm identifier if the plain text was
compressed prior to being encrypted.
contains the public key fields for the key used to encrypt the
object.
contains a value which can be used to select a key from one or
more keys the application has access to.
contains a string which identifies the content of the plain text.
There are a number of header fields defined in I-D.ietf-jose-json-
web-encryption which are not used.  These include PUT THE LIST OF
UNUSED ITEMS HERE.  Includes 'enc'?
A single COSE_encrypt element, encoded as an extension to the
containing COSE_encrypt element, for a single recipient.  Single
recipients can be encoded either this way or as a single array
element.
The plain text to be encrypted is the key from next layer down
(usually the content layer).
When direct key agreement mode is used, it MUST be the only mode used
on the message.  It is a security leak to have both direct key
agreement and a different key management mode on the same message.
When direct key agreement mode is used, it SHOULD be the only mode
used on the message.  This method creates the CEK directly and that
makes it difficult to mix with additional recipients.
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.
The restriction applies only the encoding the Sig_structure.
The restriction applies to the encoding the Sig_structure, the
Enc_structure, and the MAC_structure.
All parsers used SHOULD fail on both parsing and generation if the
same key is used twice in a map.
Considerations about protected vs unprotected header fields.