Draft: draft-ietf-cose-msg

Commentary: Change some structure names for consistency Decorate the examples .
This parameter holds a part of the IV value.  When using the
COSE_EncryptedData structure, frequently a portion of the IV is
part of the context associated with the key value.  This field is
used to carry the portion of the IV that changes for each message.
As the IV is authenticated by the encryption process, it can be
placed in the unprotected header bucket.
This parameter holds a part of the IV value.  When using the
COSE_Encrypted structure, frequently a portion of the IV is part
of the context associated with the key value.  This field is used
to carry the portion of the IV that changes for each message.  As
the IV is authenticated by the encryption process, it can be
placed in the unprotected header bucket.
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_signature,
COSE_Enveloped, COSE_recipient, COSE_EnvelopededData, COSE_mac.
These structures all have the same basic structure 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_signature,
COSE_Enveloped, COSE_recipient, COSE_Encrypted, COSE_mac.  These
structures all have the same basic structure 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_EnvelopededData
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_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).
The creation and validation of counter signatures over the different
items relies on the fact that the structure all of our 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 for 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_EnvelopededData 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 all of our 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 for 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.
COSE supports two different encryption structures.  COSE_Enveloped is
used when the key needs to be explicitly identified.  This structure
supports the use of recipient structures to allow for random content
encryption keys to be used.  COSE_Envelopeded is used when a
recipient structure is not needed because the key to be used is known
implicitly.
COSE supports two different encryption structures.  COSE_Enveloped is
used when the key needs to be explicitly identified.  This structure
supports the use of recipient structures to allow for random content
encryption keys to be used.  COSE_Enveloped is used when a recipient
structure is not needed because the key to be used is known
implicitly.