Draft: draft-ietf-cose-rfc8152bis-struct

Commentary: Review of Theresa Enghardt on May 25 .
One feature that is present in CMS RFC5652 that is not present in
this standard is a digest structure.  This omission is deliberate.
It is better for the structure to be defined in each document as
different protocols will want to include a different set of fields as
part of the structure.  While an algorithm identifier and the digest
value are going to be common to all applications, the two values may
not always be adjacent as the algorithm could be defined once with
multiple values.  Applications may additionally want to define
additional data fields as part of the structure.  A common structure
is going to include a URI or other pointer to where the data that is
being hashed is kept, allowing this to be application-specific.
COSE was initially designed as part of a solution to provide security
to Constrained RESTful Environments (CoRE), and this is done using
RFC8613 and I-D.ietf-core-groupcomm-bis.  However, COSE is not
restricted to just these cases and can be used in any place where one
would consider either JOSE or CMS RFC5652 for the purpose of
providing security services.  The use of COSE, like JOSE and CMS, is
only in store and forward or offline protocols, different solutions
would be appropriate for online protocols although one can use COSE
in and online protocol after having done some type of online key
establishment process.  Any application which uses COSE for security
services first needs to determine what security services are required
and then select the appropriate COSE structures and cryptographic
algorithms based on those needs.  app-considerations provides
additional information on what applications need to specify when
using COSE.
One feature that is present in CMS that is not present in this
standard is a digest structure.  This omission is deliberate.  It is
better for the structure to be defined in each protocol as different
protocols will want to include a different set of fields as part of
the structure.  While an algorithm identifier and the digest value
are going to be common to all applications, the two values may not
always be adjacent as the algorithm could be defined once with
multiple values.  Applications may additionally want to define
additional data fields as part of the structure.  A common structure
is going to include a URI or other pointer to where the data that is
being hashed is kept, allowing this to be application-specific.  I-
D.ietf-cose-hash-algs contains one such possible structure along with
defining a set of digest algorithms.
The COSE_Sign structure allows for one or more signatures to be
applied to a message payload.  Header parameters relating to the
content and header parameters relating to the signature are carried
along with the signature itself.  These header parameters may be
authenticated by the signature, or just present.  An example of
header a parameter about the content is the content type.  Examples
of header parameters about the signature would be the algorithm and
key used to create the signature and counter signatures.
The COSE_Sign structure allows for one or more signatures to be
applied to a message payload.  Header parameters relating to the
content and header parameters relating to the signature are carried
along with the signature itself.  These header parameters may be
authenticated by the signature, or just present.  An example of
header a parameter about the content is the content type header
parameter.  Examples of header parameters about the signature would
be the algorithm and key used to create the signature and counter
signatures.
A counter signature is normally defined as a second signature that
confirms a primary signature.  A normal example of a counter
signature is the signature that a notary public places on a document
as witnessing that you have signed the document.  Thus applying a
counter signature to either the COSE_Signature or COSE_Sign1 objects
match this traditional definition.  This document extends the context
of a counter signature to allow it to be applied to all of the
security structures defined.  It needs to be noted that the counter
signature needs to be treated as a separate operation from the
initial operation even if it is applied by the same user as is done
in I-D.ietf-core-groupcomm-bis.
The document limits the restrictions it imposes on the CBOR Encoder
needs to work.
The registries and registrations listed below were created during
processing of RFC 8152 RFC8152.  The only known action at this time
is to update the references.
The registries and registrations listed below were created during
processing of RFC 8152 RFC8152.  The majority of the actions are to
update the references to point to this document.