Draft: draft-ietf-cose-msg

Commentary: This reviews through section 10.2 ( or so ) most edits are taken as given with a couple of re - writes being suggested by me to issues raised .
Concise Binary Object Representation (CBOR) is data format designed
for small code size and small message size.  There is a need for the
ability to have the basic security services defined for this data
format.  This document defines the CBOR Object Signing and Encryption
(COSE) specification.  This specification describes how to create and
process signature, message authentication codes and encryption using
CBOR for serialization.  This specification additionally specifies
how to represent cryptographic keys using CBOR.
Concise Binary Object Representation (CBOR) is data format designed
for small code size and small message size.  There is a need for the
ability to have basic security services defined for this data format.
This document defines the CBOR Object Signing and Encryption (COSE)
specification.  This specification describes how to create and
process signature, message authentication codes and encryption using
CBOR for serialization.  This specification additionally specifies
how to represent cryptographic keys using CBOR.
There has been an increased focus on the small, constrained devices
that make up the Internet of Things (IoT).  One of the standards that
has come out of this process is the Concise Binary Object
Representation (CBOR) RFC7049.  CBOR extended the data model of the
JavaScript Object Notation (JSON) RFC7159 by allowing for binary
data, among other changes.  CBOR is being adopted by several of the
IETF working groups dealing with the IoT world as their encoding of
data structures.  CBOR was designed specifically to be both small in
terms of messages transport and implementation size, as well having a
schema free decoder.  A need exists to provide message security
services for IoT and using CBOR as the message encoding format makes
sense.
There has been an increased focus on small, constrained devices that
make up the Internet of Things (IoT).  One of the standards that has
come out of this process is the Concise Binary Object Representation
(CBOR) RFC7049.  CBOR extended the data model of the JavaScript
Object Notation (JSON) RFC7159 by allowing for binary data, among
other changes.  CBOR is being adopted by several of the IETF working
groups dealing with the IoT world as their encoding of data
structures.  CBOR was designed specifically to be both small in terms
of messages transport and implementation size, as well having a
schema free decoder.  A need exists to provide message security
services for IoT, using CBOR as the message encoding format makes
sense.
Define a single top message structure so that encrypted, signed
and MACed messages can easily identified and still have a
consistent view.
Signed messages separate the concept of protected and unprotected
parameters that are for the content and the signature.
Define a single top message structure so that encrypted, signed
and MACed messages can easily be identified and still have a
consistent view.
Signed messages distinguish between the protected and unprotected
parameters that relate to the content from those that relate to
the signature.
Contains parameters about the current layer that are to be
cryptographically protected.  This bucket MUST be empty if it is
not going to be included in a cryptographic computation.  This
bucket is encoded in the message as a binary object.  This value
is obtained by CBOR encoding the protected map and wrapping it in
a bstr object.  Senders SHOULD encode an zero length map as a zero
length string rather than as a zero length map (encoded as h'a0').
The zero length binary encoding is preferred because it is both
shorter and the version used in the serialization structures for
cryptographic computation.  After encoding the map the value is
wrapped in the binary object.  Recipients MUST accept both a zero
length binary value and a zero length map encoded in the binary
value.  The wrapping allows for the encoding of the protected map
to be transported with a greater chance that it will not be
altered in transit.  (Badly behaved intermediates could decode and
re-encode, but this will result in a failure to verify unless the
re-encoded byte string is identical to the decoded byte string.)
This avoids the problem of all parties needing to be able to do a
common canonical encoding.
Contains parameters about the current layer that are to be
cryptographically protected.  This bucket MUST be empty if it is
not going to be included in a cryptographic computation.  This
bucket is encoded in the message as a binary object.  This value
is obtained by CBOR encoding the protected map and wrapping it in
a bstr object.  Senders SHOULD encode a zero length map as a zero
length string rather than as a zero length map (encoded as h'a0').
The zero length binary encoding is preferred because it is both
shorter and the version used in the serialization structures for
cryptographic computation.  After encoding the map, the value is
wrapped in the binary object.  Recipients MUST accept both a zero
length binary value and a zero length map encoded in the binary
value.  The wrapping allows for the encoding of the protected map
to be transported with a greater chance that it will not be
altered in transit.  (Badly behaved intermediates could decode and
re-encode, but this will result in a failure to verify unless the
re-encoded byte string is identical to the decoded byte string.)
This avoids the problem of all parties needing to be able to do a
common canonical encoding.
COSE supports two different signature structures.  COSE_Sign allows
for one or more signers to be applied to a single content.
COSE_Sign1 is restricted to a single signer.  The structures cannot
be converted between each other; as the signature computation
includes a parameter identifying which structure is being used, the
converted structure will fail signature validation.
COSE supports two different signature structures.  COSE_Sign allows
for one or more signatures to be applied to the same content.
COSE_Sign1 is restricted to a single signer.  The structures cannot
be converted between each other; as the signature computation
includes a parameter identifying which structure is being used, the
converted structure will fail signature validation.
The COSE_Sign structure allows for one or more signatures to be
applied to a message payload.  There are provisions for parameters
about the content and parameters about the signature to be carried
along with the signature itself.  These parameters may be
authenticated by the signature, or just present.  An example of a
parameter about the content is the content type.  Examples of
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.  Parameters relating to the content and
parameters relating to the signature are carried along with the
signature itself.  These parameters may be authenticated by the
signature, or just present.  An example of a parameter about the
content is the content type.  Examples of parameters about the
signature would be the algorithm and key used to create the signature
and counter signatures.
When more than one signature is present, the successful validation of
one signature associated with a given signer is usually treated as a
successful signature by that signer.  However, there are some
application environments where other rules are needed.  An
application that employs a rule other than one valid signature for
each signer must specify those rules.  Also, where simple matching of
the signer identifier is not sufficient to determine whether the
signatures were generated by the same signer, the application
specification must describe how to determine which signatures were
generated by the same signer.  Support of different communities of
recipients is the primary reason that signers choose to include more
than one signature.  For example, the COSE_Sign structure might
include signatures generated with the Edwards Digital Signature
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.
When more than one signature is present, the successful validation of
one signature associated with a given signer is usually treated as a
successful signature by that signer.  However, there are some
application environments where other rules are needed.  An
application that employs a rule other than one valid signature for
each signer must specify those rules.  Also, where simple matching of
the signer identifier is not sufficient to determine whether the
signatures were generated by the same signer, the application
specification must describe how to determine which signatures were
generated by the same signer.  Support for different communities of
recipients is the primary reason that signers choose to include more
than one signature.  For example, the COSE_Sign structure might
include signatures generated with the Edwards Digital Signature
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.
Message Authentication Codes (MACs) provide data authentication and
integrity protection.  They provide either no or very limited data
origination.  A MAC, for example, be used to prove the identity of
the sender to a third party.
If the 'alg' field present, it MUST match the HMAC algorithm being
used.
If the 'alg' field is present, it MUST match the HMAC algorithm
being used.
HMAC has proved to be resistant to attack even when used with
weakened hash algorithms.  The current best method appears to be a
brute force attack on the key.  This means that key size is going to
be directly related to the security of an HMAC operation.
HMAC has proved to be resistant to attack even when used with
weakened hash algorithms.  The current best known attack appears is
to brute force the key.  This means that key size is going to be
directly related to the security of an HMAC operation.
If the 'alg' field present, it MUST match the AES-MAC algorithm
being used.
If the 'alg' field is present, it MUST match the AES-MAC algorithm
being used.
A number of attacks exist against CBC-MAC that need to be considered.
If the same key is used for both encryption and authentication
operations, using CBC modes an attacker can produce messages with
a valid authentication code.
When using CBC mode, if the same key is used for both encryption
and authentication operations, an attacker can produce messages
with a valid authentication code.
If the 'alg' field present, it MUST match the AES-GCM algorithm
being used.
If the 'alg' field is present, it MUST match the AES-GCM algorithm
being used.
We define a matrix of algorithms in this document over the values of
L and M.  Constrained devices are usually operating in situations
where they use short messages and want to avoid doing recipient
specific cryptographic operations.  This favors smaller values of
both L and M.  Less constrained devices will want to be able to user
larger messages and are more willing to generate new keys for every
operation.  This favors larger values of L and M.
We define a matrix of algorithms in this document over the values of
L and M.  Constrained devices are usually operating in situations
where they use short messages and want to avoid doing recipient
specific cryptographic operations.  This favors smaller values of
both L and M.  Less constrained devices will want to be able to use
larger messages and are more willing to generate new keys for every
operation.  This favors larger values of L and M.
If the 'alg' field present, it MUST match the AES-CCM algorithm
being used.
If the 'alg' field is present, it MUST match the AES-CCM algorithm
being used.
If the 'alg' field present, it MUST match the ChaCha20/Poly1305
algorithm being used.
If the 'alg' field is present, it MUST match the ChaCha20/Poly1305
algorithm being used.
If the 'alg' field present, it MUST match the algorithm being
used.
If the 'alg' field is present, it MUST match the algorithm being
used.
While these methods do not provide for PFS, as the same shared secret
is used for all of the keys generated, if the key for any single
message is discovered only the message (or series of messages) using
that derived key are compromised.  A new key derivation step will
generate a new key which requires the same amount of work to get the
key.
While these methods do not provide for perfect forward secrecy, as
the same shared secret is used for all of the keys generated, if the
key for any single message is discovered only the message (or series
of messages) using that derived key are compromised.  A new key
derivation step will generate a new key which requires the same
amount of work to get the key.
The 'recipients' field is normally absent, but can be used.
Applications MUST deal with a recipient field present, not being
able to decrypt that recipient is an acceptable way of dealing
with it.  Failing to process the message is not an acceptable way
of dealing with it.
The 'recipients' field is normally absent, but can be used.
Applications MUST deal with a recipient field being present, not
being able to decrypt that recipient is an acceptable way of
dealing with it.  Failing to process the message is not an
acceptable way of dealing with it.
Applications are therefore intended to profile the usage of this
document.  This section provides a set of guidelines and topics that
applications need to consider when using this document.
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 requested that IANA create a new registry entitled "COSE Header
Parameters".  The registry is to be created as Expert Review
Required.  Expert review guidelines are provided in review.
It is requested that IANA create a new registry entitled "COSE Header
Parameters".  The registry should be created as Expert Review
Required.  Guidelines for the experts is provided review.  It should
be noted that in additional to the expert review, some portions of
the registry require a specification, potentially on standards track,
be supplied as well.
It is requested that IANA create a new registry entitled "COSE
Algorithms Registry".  The registry is to be created as Expert Review
Required.  Expert review guidelines are provided in review.
It is requested that IANA create a new registry entitled "COSE
Algorithms Registry".  The registry is to be created as Expert Review
Required.  Guidelines for the experts is provided review.  It should
be noted that in additional to the expert review, some portions of
the registry require a specification, potentially on standards track,
be supplied as well.
It is requested that IANA create a new registry entitled "COSE Key
Common Parameters" registry.  The registry is to be created as Expert
Review Required.  Expert review guidelines are provided in review.
It is requested that IANA create a new registry entitled "COSE Key
Common Parameters" registry.  The registry is to be created as Expert
Review Required.  Guidelines for the experts is provided review.  It
should be noted that in additional to the expert review, some
portions of the registry require a specification, potentially on
standards track, be supplied as well.
It is requested that IANA create a new registry "COSE Key Type
Registry"> The registry is to be created as Expert Review Required.
Expert review guidelines are provided in review.
It is requested that IANA create a new registry "COSE Key Type
Registry".  The registry is to be created as Expert Review Required.
Expert review guidelines are provided in review.
It is requested that IANA create a new registry "COSE Elliptic Curve
Parameters".  The registry is to be created as Expert Review
Required.  Expert review guidelines are provided in review.
It is requested that IANA create a new registry "COSE Elliptic Curve
Parameters".  The registry is to be created as Expert Review
Required.  Guidelines for the experts is provided review.  It should
be noted that in additional to the expert review, some portions of
the registry require a specification, potentially on standards track,
be supplied as well.
Experts should take into account the expected usage of fields when
approving point assignment.  The fact that there is a range for
standards track documents does not mean that a standards track
document cannot have points assigned outside of that range.  Some
of the ranges are restricted in range, items that are not expected
to be common or are not expected to be used in constrained
environments should be assigned to values which will encode to
longer byte strings.
Experts should take into account the expected usage of fields when
approving point assignment.  The fact that there is a range for
standards track documents does not mean that a standards track
document cannot have points assigned outside of that range.  The
length of the encoded value should be weighed against how many
code points of that length are left, the size of device it will be
used on, and the number of code points left that encode to that
size.
Use of 'direct' as a recipient algorithm combined with a second
recipient algorithm, either directly in a separate message,
exposes the direct key to the second recipient.
Use of 'direct' as a recipient algorithm combined with a second
recipient algorithm, exposes the direct key to the second
recipient.