Draft: draft-schaad-cose

Commentary: The document is updated to use the CDDL grammer from the latest version ( -05 ) Fixed a couple of small errors where my thinking and my text did not match .
There currently is no standard CBOR grammar available for use by
specifications.  In this document, we use a modified version of the
CBOR data definition language (CDDL) defined in I-D.greevenbosch-
appsawg-cbor-cddl.  The differences between the defined grammar and
the one we used are mostly self explanatory.  The biggest difference
being the addition of the choice operator '|'.  Additionally, note
the use of the null value which is used to occupy a location in an
array but to mark that the element is not present.
There currently is no standard CBOR grammar available for use by
specifications.  In this document, we use the grammar defined in the
CBOR data definition language (CDDL) I-D.greevenbosch-appsawg-cbor-
cddl.
contains the information about the plain text or encryption
process that is to be integrity protected.  The field is encoded
in CBOR as a 'bstr' if present and the value 'null' if there is no
data.  The contents of the protected field is a CBOR map of the
protected data names and values.  The map is CBOR encoded before
placing it into the bstr.  Only values associated with the current
cipher text are to be placed in this location even if the value
would apply to multiple recipient structures.
contains the information about the plain text or encryption
process that is to be integrity protected.  The field is encoded
in CBOR as a 'bstr' if present and the value 'nil' if there is no
data.  The contents of the protected field is a CBOR map of the
protected data names and values.  The map is CBOR encoded before
placing it into the bstr.  Only values associated with the current
cipher text are to be placed in this location even if the value
would apply to multiple recipient structures.
contains information about the plain text that is not integrity
protected.  If there are no field, then the value 'null' is used.
Only values associated with the current cipher text are to be
placed in this location even if the value would apply to multiple
recipient structures.
contains the initialization vector (IV), or it's equivalent, if
one is needed by the encryption algorithm.  If there is no IV,
then the value 'null' is used.
contains additional authenticated data (aad) supplied by the
application.  This field contains information about the plain text
data that is authenticated, but not encrypted.  If the application
does not provide this data, the value 'null' is used.
contains the encrypted plain text.  If the cipherText is to be
transported independently of the control information about the
encryption process (i.e. detached content) then the value 'null'
is encoded here.
contains information about the plain text that is not integrity
protected.  If there are no field, then the value 'nil' is used.
Only values associated with the current cipher text are to be
placed in this location even if the value would apply to multiple
recipient structures.
contains the initialization vector (IV), or it's equivalent, if
one is needed by the encryption algorithm.  If there is no IV,
then the value 'nil' is used.
contains additional authenticated data (aad) supplied by the
application.  This field contains information about the plain text
data that is authenticated, but not encrypted.  If the application
does not provide this data, the value 'nil' is used.
contains the encrypted plain text.  If the cipherText is to be
transported independently of the control information about the
encryption process (i.e. detached content) then the value 'nil' is
encoded here.
A 'null' value if there are no recipients.
A 'nil' value if there are no recipients.
In direct encryption mode, a shared secret between the sender and the
recipient is used as the CEK.  For direct encryption mode, no
recipient structure is built.  All of the information about the key
is placed in either the protected or unprotected fields at the
content level.  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 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', 'iv', 'aad', 'ciphertext' and 'recipients' fields
MUST be null.
The 'protected', 'iv', 'aad', 'ciphertext' and 'recipients' fields
MUST be nil.
The 'protected', 'aad', and 'recipients' fields MUST be null.
The 'protected', 'aad', and 'recipients' fields MUST be nil.
Direct Key Agreement derives the CEK from the shared secret computed
by the key agreement operation.  For Direct Key Agreement, no
recipient structure is built.  All of the information about the key
and key agreement process is placed in either the 'protected' or
'unprotected' fields at the content level.
Direct Key Agreement derives the CEK from the shared secret computed
by the key agreement operation.