Draft: draft-ietf-cose-msg

Commentary: Change COSEEnveloped to COSEEncrypt and COSEEncrypted to COSEEncrypt1
This parameter holds a counter signature value.  Counter
signatures provide a method of having a second party sign some
data.  The counter signature can occur as an unprotected attribute
in any of the following structures: COSE_Sign, COSE_Sign1,
COSE_Signature, COSE_Enveloped, COSE_recipient, COSE_Encrypted,
COSE_Mac and COSE_Mac0.  These structures all have the same
beginning elements so that a consistent calculation of the counter
signature can be computed.  Details on computing counter
signatures are found in counter_signature.
This parameter holds a counter signature value.  Counter
signatures provide a method of having a second party sign some
data.  The counter signature can occur as an unprotected attribute
in any of the following structures: COSE_Sign, COSE_Sign1,
COSE_Signature, COSE_Encrypt, COSE_recipient, COSE_Encrypt1,
COSE_Mac and COSE_Mac0.  These structures all have the same
beginning elements so that a consistent calculation of the counter
signature can be computed.  Details on computing counter
signatures are found in counter_signature.
Counter signatures provide a method of having a different signature
occur on some piece of content.  This is normally used to provide a
signature on a signature allowing for a proof that a signature
existed at a given time (i.e. a Timestamp).  In this document we
allow for counter signatures to exist in a greater number of
environments.  As an example, it is possible to place a counter
signature in the unprotected attributes of a COSE_Enveloped object.
This would allow for an intermediary to either verify that the
encrypted byte stream has not been modified, without being able to
decrypt it.  Or for the intermediary to assert that an encrypted byte
stream either existed at a given time or passed through it in terms
of routing (i.e. a proxy signature).
Counter signatures provide a method of having a different signature
occur on some piece of content.  This is normally used to provide a
signature on a signature allowing for a proof that a signature
existed at a given time (i.e. a Timestamp).  In this document we
allow for counter signatures to exist in a greater number of
environments.  As an example, it is possible to place a counter
signature in the unprotected attributes of a COSE_Encrypt object.
This would allow for an intermediary to either verify that the
encrypted byte stream has not been modified, without being able to
decrypt it.  Or for the intermediary to assert that an encrypted byte
stream either existed at a given time or passed through it in terms
of routing (i.e. a proxy signature).
The creation and validation of counter signatures over the different
items relies on the fact that the structure of the objects have the
same structure.  The elements are a set of protected attributes, a
set of unprotected attributes and a body in that order.  This means
that the Sig_structure can be used in a uniform manner to get the
byte stream for processing a signature.  If the counter signature is
going to be computed over a COSE_Enveloped structure, the
body_protected and payload items can be mapped into the Sig_structure
in the same manner as from the COSE_Sign structure.
The creation and validation of counter signatures over the different
items relies on the fact that the structure of the objects have the
same structure.  The elements are a set of protected attributes, a
set of unprotected attributes and a body in that order.  This means
that the Sig_structure can be used in a uniform manner to get the
byte stream for processing a signature.  If the counter signature is
going to be computed over a COSE_Encrypt structure, the
body_protected and payload items can be mapped into the Sig_structure
in the same manner as from the COSE_Sign structure.
COSE supports two different encryption structures.  COSE_Encrypted is
used when a recipient structure is not needed because the key to be
used is known implicitly.  COSE_Enveloped is used the rest of time.
This includes cases where there are multiple recipients, a recipient
algorithm other than direct is to be used, or the key to be used is
not known.
COSE supports two different encryption structures.  COSE_Encrypt1 is
used when a recipient structure is not needed because the key to be
used is known implicitly.  COSE_Encrypt is used the rest of time
time.  This includes cases where there are multiple recipients, a
recipient algorithm other than direct is to be used, or the key to be
used is not known.
The same techniques and structures are used 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 RFC7516 where different
structures are used for the content layer and for the recipient
layer.  Two structures are defined: COSE_Enveloped to hold the
encrypted content, and COSE_recipient to hold the encrypted keys for
recipients.  Examples of encrypted messages can be found in
EnvelopedExamples.
The same techniques and structures are used 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 RFC7516 where different
structures are used for the content layer and for the recipient
layer.  Two structures are defined: COSE_Encrypt to hold the
encrypted content, and COSE_recipient to hold the encrypted keys for
recipients.  Examples of encrypted messages can be found in
EnvelopedExamples.
The structure defined to hold an encrypted message is COSE_Encrypted.
Examples of encrypted messages can be found in EnvelopedExamples.
The COSE_Encrypted structure can be encoded either with or without a
tag depending on the context it will be used in.  The COSE_Encrypted
structure is identified by the CBOR tag TBD3.  The CDDL fragment that
represents this is.
The structure defined to hold an encrypted message is COSE_Encrypt1.
Examples of encrypted messages can be found in EnvelopedExamples.
The COSE_Encrypt1 structure can be encoded either with or without a
tag depending on the context it will be used in.  The COSE_Encrypt1
structure is identified by the CBOR tag TBD3.  The CDDL fragment that
represents this is.
It is requested that IANA assign the following tags from the "Concise
Binary Object Representation (CBOR) Tags" registry.  It is requested
that the tags for COSE_Sign1, COSE_Encrypted and COSE_Mac0 be
assigned in the 1 to 23 value range (i.e. one byte long when
encoded).  It is requested that the rest of the tags be assigned in
the 24 to 255 value range (i.e. two bytes long when encoded).
It is requested that IANA assign the following tags from the "Concise
Binary Object Representation (CBOR) Tags" registry.  It is requested
that the tags for COSE_Sign1, COSE_Encrypt1 and COSE_Mac0 be assigned
in the 1 to 23 value range (i.e. one byte long when encoded).  It is
requested that the rest of the tags be assigned in the 24 to 255
value range (i.e. two bytes long when encoded).
NOTE: The assignment of algorithm identifiers in this document was
done so that positive numbers were used for the first level objects
(COSE_Sign, COSE_Sign1, COSE_Enveloped, COSE_Encrypted, COSE_Mac and
COSE_Mac0).  Negative numbers were used for second level objects
(COSE_Signature and COSE_recipient).  Expert reviewers should
consider this practice, but are not expected to be restricted by this
precedent.
NOTE: The assignment of algorithm identifiers in this document was
done so that positive numbers were used for the first level objects
(COSE_Sign, COSE_Sign1, COSE_Encrypt, COSE_Encrypt1, COSE_Mac and
COSE_Mac0).  Negative numbers were used for second level objects
(COSE_Signature and COSE_recipient).  Expert reviewers should
consider this practice, but are not expected to be restricted by this
precedent.