Draft: draft-ietf-cose-rfc8152bis-struct

Commentary: This PR addresses the remaining comments from   . 
 do these changes match your expectations ? 
 Ah , that 's the one . Will add . 
 I do note that Göran 's name is still too " ASCII - ized " ; how to include the unicode here is not immediately clear ( it 's not in an \<author/ , it 's not \<artwork , etc ) . I suggest adding an RFC Editor 's note about it ? 
 Looking again , there is a CBOR Tags section in this document , at the end of the IANA section instead of the beginning . I think we 're good to go , once this is merged . 
 This looks pretty good ( some suggestions inline ) . Comparing against my ballot position ( at ) , I do n't see anything to match : incorporated still ( and the report verified , presuming it is correct ) . but my recollection is that that one is already incorporated , just into -algs , and I should mark it verified and allocating a codepoint for COSE_Signature ) . I think we need to bring back a stub section with the directive to update the references from 8152 to this document . which may still be outstanding ( I do n't remember any other clarifications about that point having gone by ) .
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 for use in store and forward or offline protocols.  The use of
COSE in online protocols needing encryption, require that an online
key establishment process be done before sending objects back and
forth.  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.
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.  COSE, like JOSE and CMS, is only for
use in store and forward or offline protocols.  The use of COSE in
online protocols needing encryption, require that an online key
establishment process be done before sending objects back and forth.
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 one such
application-specific element would be to include a URI or other
pointer to where the data that is being hashed can be obtained.  I-
D.ietf-cose-hash-algs contains one such possible structure along with
defining a set of digest algorithms.
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.  One such
application-specific element would be to include a URI or other
pointer to where the data that is being hashed can be obtained.  I-
D.ietf-cose-hash-algs contains one such possible structure along with
defining a set of digest algorithms.
The presence a label that is neither a a text string or an integer,
in a CBOR map, is an error.  Applications can either fail processing
or process messages by ignoring incorrect labels; however, they MUST
NOT create messages with incorrect labels.
The presence a label that is neither a text string or an integer, in
a CBOR map, is an error.  Applications can either fail processing or
process messages by ignoring incorrect labels; however, they MUST NOT
create messages with incorrect labels.
COSE messages are built using the concept of 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.  The content layer contains the plaintext is
encrypted and information about the encrypted message.  The recipient
layer contins the content encryption key (CEK) is encrypted and
information about how it is encrypted for each recipient.  A single
layer version of the encryption message COSE_Encrypt0
(EnvelopedData0) is provided for cases where the CEK is pre-shared.
COSE messages are built using the concept of 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.  The content layer contains the encrypted plaintext
and information about the encrypted message.  The recipient layer
contains the encrypted content encryption key (CEK) and information
about how it is encrypted for each recipient.  A single layer version
of the encryption message COSE_Encrypt0 (EnvelopedData0) is provided
for cases where the CEK is pre-shared.
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 a
header parameter about the content is the content type header
parameter.  An examples of a header parameter about the signature
would be the algorithm and key used to create the signature.
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 a
header parameter about the content is the content type header
parameter.  An example of a header parameter about the signature
would be the algorithm and key used to create the signature.
appendix schemes in a single message is not supported, and if a
recovery signature scheme is used.
appendix schemes in a single message is not supported.
No message recovery signature algorithms have been formally defined
for COSE yet, and given the new constraints arising from this
schemes, while some of these issues have already been identified
there is a high probability that additional issues will arise when
integrating message recovery signature algorithms.  The first
algorithm defined is going to need to make decisions about these
issues and those decisions re likely to be binding on any further
algorithms defined.
No message recovery signature algorithms have been formally defined
for COSE yet, and given the new constraints arising from this
schemes, while some of these issues have already been identified
there is a high probability that additional issues will arise when
integrating message recovery signature algorithms.  The first
algorithm defined is going to need to make decisions about these
issues and those decisions are likely to be binding on any further
algorithms defined.
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.
IANA created a registry titled "COSE Header Parameters" as part of
processing RFC8152.  IANA is requested to update the reference for
all entries, except "counter signature" and "CounterSignature0", in
the table from RFC8152 to this document.  The reference for "counter
signature" and "CounterSignature0" are to be left alone.
IANA created a registry titled "COSE Key Common Parameters" as part
of the processing of RFC8152.  IANA is requested to update the
reference for entries in the table from RFC8152 to this document.
The registries and registrations listed below were created during
processing of RFC 8152 RFC8152.  The majority of the following
actions are to update the references to point to this document.
Note that while I-D.ietf-cose-rfc8152bis-algs also updates the
registries and registrations originally established by RFC8152, the
requested updates are mutually exclusive.  The updates requested in
this document do not conflict or overlap with the updates requested
in I-D.ietf-cose-rfc8152bis-algs, and vice versa.
IANA created a registry titled "COSE Header Parameters" as part of
processing RFC8152.  IANA is requested to update the reference for
this registry from RFC8152 to this document.  IANA is also requested
to update the reference for all entries, except "counter signature"
and "CounterSignature0", in the table from RFC8152 to this document.
The reference for "counter signature" and "CounterSignature0" are to
be left as-is.
IANA created a registry titled "COSE Key Common Parameters" as part
of the processing of RFC8152.  IANA is requested to update the
reference for this registry from RFC8152 to this document.  IANA is
also requested to update the reference for entries in the table from
RFC8152 to this document.