Draft: draft-ietf-cose-msg

Commentary: Start working on re - integrating the CDDL fragments back into the body .
There currently is no standard CBOR grammar available for use by
specifications.  We therefore describe the CBOR structures in prose.
There is a version of a CBOR grammar in the CBOR Data Definition
Language (CDDL) I-D.greevenbosch-appsawg-cbor-cddl.  An informational
version of the CBOR grammar that reflects what is in the prose can be
found in Grammar_Appendix.  Since CDDL has not be published as an
RFC, this grammar may not work with the final version of CDDL when it
is published.
There currently is no standard CBOR grammar available for use by
specifications.  We therefore describe the CBOR structures in prose.
any - non-specific value that permits all CBOR values to be placed
here.
NOTE: For the purposes of review, we are currently interlacing the
CDDL grammar into the text of document.  This is being done for
simplicity of comparison of the grammar against the prose.  The
grammar will be removed to an appendix during WGLC.
There is a version of a CBOR grammar in the CBOR Data Definition
Language (CDDL) I-D.greevenbosch-appsawg-cbor-cddl.  Since CDDL has
not be published as an RFC, this grammar may not work with the final
version of CDDL when it is published.  For those people who prefer
using a formal language to describe the syntax of the CBOR, an
informational version of the CBOR grammar is interweaved into the
text as well.  The CDDL grammar is informational, the prose
description is normative.
CDDL expects the initial non-terminal symbol to be the first symbol
in the file.  For this reason the first fragment of CDDL is presented
here.
The non-terminal Internal_Types is defined for dealing with the
automated validation tools used during the writing of this document.
It references those non-terminals that are used for security
computations.
A CDDL grammar fragment is defined that defines the non-terminals
'label' as in the previous paragraph and 'values' which permits any
value to be used.
The following CDDL fragment identifies all of the top level messages
defined in this document.  Separate non-terminals are defined for the
tagged and the untagged versions of the messages for the convenience
of applications.
The following CDDL fragment represents the two header buckets.  A
group Headers is defined in CDDL which represents the two buckets in
which attributes are placed.  This group is used to provide these two
fields consistently in all locations.  A type is also defined which
represents the map of header values.  It uses forward references to a
group definition of headers for generic and algorithms.
This parameter is used to indicate the content type of the data in
the payload or ciphertext fields.  Integers are from the 'CoAP
Content-Formats' IANA registry table.  [CREF4] 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 ciphertext fields.  Integers are from the 'CoAP
Content-Formats' IANA registry table.  [CREF3] Strings are from
the IANA 'Media Types' registry.  Applications SHOULD provide this
parameter if the content structure is potentially ambiguous.
The CDDL fragment that represents the set of headers defined in this
section is given below.  Each of the headers is tagged as optional
because they do not need to be in every map, headers required in
specific maps are discussed above.
The signature structure allows for one or more signatures to be
applied to a message payload.  There are provisions for parameters
about the content and parameters about the signature to be carried
along with the signature itself.  These parameters may be
authenticated by the signature, or just present.  Examples of
parameters about the content would be the type of content, when the
content was created, and who created the content.  [CREF5] Examples
of parameters about the signature would be the algorithm and key used
to create the signature, when the signature was created, and counter-
signatures.
The signature structure allows for one or more signatures to be
applied to a message payload.  There are provisions for parameters
about the content and parameters about the signature to be carried
along with the signature itself.  These parameters may be
authenticated by the signature, or just present.  Examples of
parameters about the content would be the type of content, when the
content was created, and who created the content.  [CREF4] Examples
of parameters about the signature would be the algorithm and key used
to create the signature, when the signature was created, and counter-
signatures.
One of the features that we supply in the COSE document is the
ability for applications to provide additional data to be
authenticated as part of the security, but that is not carried as
part of the COSE object.  The primary reason for supporting this can
be seen by looking at the CoAP message structure RFC7252 where the
facility exists for options to be carried before the payload.
[CREF6] An example of data that can be placed in this location would
be transaction ids and nonces to check for replay protection.  If the
data is in the options section, then it is available for routers to
help in performing the replay detection and prevention.  However, it
may also be desired to protect these values so that they cannot be
modified in transit.  This is the purpose of the externally supplied
data field.
One of the features that we supply in the COSE document is the
ability for applications to provide additional data to be
authenticated as part of the security, but that is not carried as
part of the COSE object.  The primary reason for supporting this can
be seen by looking at the CoAP message structure RFC7252 where the
facility exists for options to be carried before the payload.
[CREF5] An example of data that can be placed in this location would
be transaction ids and nonces to check for replay protection.  If the
data is in the options section, then it is available for routers to
help in performing the replay detection and prevention.  However, it
may also be desired to protect these values so that they cannot be
modified in transit.  This is the purpose of the externally supplied
data field.
One of the issues that needs to be addressed is a requirement that a
standard specify a set of algorithms that are required to be
implemented.  [CREF10] This is done to promote interoperability as it
provides a minimal set of algorithms that all devices can be sure
will exist at both ends.  However, we have elected not to specify a
set of mandatory algorithms in this document.
One of the issues that needs to be addressed is a requirement that a
standard specify a set of algorithms that are required to be
implemented.  [CREF9] This is done to promote interoperability as it
provides a minimal set of algorithms that all devices can be sure
will exist at both ends.  However, we have elected not to specify a
set of mandatory algorithms in this document.