Draft: draft-ietf-cose-msg

Commentary: Typo comments from    to issue comments to follow
COSE messages are also built using the concept of using 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.  In the content layer, the plain text is
encrypted and information about the encrypted message are placed.  In
the recipient layer, the content encryption key (CEK) is encrypted
and information about how it is encrypted for each recipient is
placed.  A single layer version of the encryption message
COSE_Encrypt0 (EnvelopedData0) is provided for cases where the CEK is
pre-shared.
COSE messages are also 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.  In the content layer, the plain text is encrypted
and information about the encrypted message are placed.  In the
recipient layer, the content encryption key (CEK) is encrypted and
information about how it is encrypted for each recipient is placed.
A single layer version of the encryption message COSE_Encrypt0
(EnvelopedData0) is provided for cases where the CEK is pre-shared.
Both buckets are implemented as CBOR maps.  The map key is a 'label'
(label).  The value portion is dependent on the definition for the
label.  Both maps use the same set of label/value pairs.  The integer
and string values for labels has been divided into several sections
with a standard range, a private range, and a range that is dependent
on the algorithm selected.  The defined labels can be found in the
"COSE Header Parameters" IANA registry (cose-header-key-table).
Both buckets are implemented as CBOR maps.  The map key is a 'label'
(label).  The value portion is dependent on the definition for the
label.  Both maps use the same set of label/value pairs.  The integer
and string values for labels have been divided into several sections
with a standard range, a private range, and a range that is dependent
on the algorithm selected.  The defined labels can be found in the
"COSE Header Parameters" IANA registry (cose-header-key-table).
Labels in each of the maps MUST be unique.  When processing messages,
if a label appears multiple times, the message MUST be rejected as
malformed.  Applications SHOULD perform the same checks that the same
label does not occur in both the protected and unprotected headers.
If the message is not rejected as malformed, attributes MUST be
obtained from the protected bucket before they are obtained from the
unprotected bucket.
Labels in each of the maps MUST be unique.  When processing messages,
if a label appears multiple times, the message MUST be rejected as
malformed.  Applications SHOULD verify that the same label does not
occur in both the protected and unprotected headers.  If the message
is not rejected as malformed, attributes MUST be obtained from the
protected bucket before they are obtained from the unprotected
bucket.
Algorithm (EdDSA) signature algorithm and with the Elliptic Curve
Digital Signature Algorithm (ECDSA) signature algorithm.  This allows
recipients to verify the signature associated with one algorithm or
the other.  (The original source of this text is RFC5652.)  More
detailed information on multiple signature evaluation can be found in
RFC5752.
Algorithm (EdDSA) I-D.irtf-cfrg-eddsa signature algorithm and with
the Elliptic Curve Digital Signature Algorithm (ECDSA) DSS signature
algorithm.  This allows recipients to verify the signature associated
with one algorithm or the other.  (The original source of this text
is RFC5652.)  More detailed information on multiple signature
evaluation can be found in RFC5752.
The COSE_Sign1 signature structure is used when only one signer is
going to be placed on a message.  The parameters dealing with the
content and the signature are placed in the same pair of buckets
rather than having the separation of COSE_Sign.
The COSE_Sign1 signature structure is used when only one signature is
going to be placed on a message.  The parameters dealing with the
content and the signature are placed in the same pair of buckets
rather than having the separation of COSE_Sign.
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).
Counter signatures provide a method of associating different
signature generated by different signers with 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 key is randomly generated.
The key is randomly or pseudo-randomly generated.
yourself.)  The origination property can be obtained with both of the
MAC message structures.
to yourself.)  The origination property can be obtained with both of
the MAC message structures.
It is intended that a profile of this document be created that
defines the interopability requirements for that specific
application.  This section provides a set of guidelines and topics
that need to be considered when profiling this document.
It is intended that a profile of this document be created that
defines the interoperability requirements for that specific
application.  This section provides a set of guidelines and topics
that need to be considered when profiling this document.