Draft: draft-ietf-cose-msg

Commentary: Line 1832 should be a single minus - it is a subtraction operation . 
 Oh , of course . Fixed ( including the spurious space in front of the period ) .
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 of of this process is the Concise Binary Object
Representation (CBOR).  CBOR extended the data model of the
JavaScript Object Notation (JSON) 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 basic message security
services for IOT and using CBOR as the message encoding format makes
sense.
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).  CBOR extended the data model of the
JavaScript Object Notation (JSON) 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 basic message security
services for IOT and using CBOR as the message encoding format makes
sense.
nil - a null value (tag 7.22).
nil - a null value (major type 7, value 22).
NOTE: For the purposes of review, we are currently interlacing the
CDLL grammar into the text of document.  This is being done for
simplicity of comparision of the grammar againist the prose.  The
grammar will be removed to an appendix during WGLC.
NOTE: For the purposes of review, we are currently interlacing the
CDDL grammar into the text of document.  This is being done for
simplicity of comparison of the grammar against the prose.  The
grammar will be removed to an appendix during WGLC.
One of the features that we supply in the COSE document is the
ability for applications to provide additional data to be
authenticated as part of the security, but that is not carried as
part of the COSE object.  The primary reason for supporting this can
be seen by looking at the CoAP message struture RFC7252 where the
facility exists for options to be carried before the payload.  An
example of data that can be placed in this location would be
transaction ids and nonces to check for replay protection.  If the
data is in the options section, then it is available for routers to
help in performing the replay detection and prevention.  However, it
may also be desired to protect these values so that they cannot be
modified in transit.  This is the purpose of the externally supplied
data field.
One of the features that we supply in the COSE document is the
ability for applications to provide additional data to be
authenticated as part of the security, but that is not carried as
part of the COSE object.  The primary reason for supporting this can
be seen by looking at the CoAP message structure RFC7252 where the
facility exists for options to be carried before the payload.  An
example of data that can be placed in this location would be
transaction ids and nonces to check for replay protection.  If the
data is in the options section, then it is available for routers to
help in performing the replay detection and prevention.  However, it
may also be desired to protect these values so that they cannot be
modified in transit.  This is the purpose of the externally supplied
data field.
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.  In this document we allow for counter
signatures to exist in a greater number of environments.  A counter
signature can exist, for example, on a COSE_encyptedData object and
allow for a signature to be present on the encrypted content of a
message.
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.  In this document we allow for counter
signatures to exist in a greater number of environments.  A counter
signature can exist, for example, on a COSE_encryptedData object and
allow for a signature to be present on the encrypted content of a
message.
COSE supports two different encryption structures.  OOSE_enveloped is
used when the key needs to be explicilty identified.  This structure
supports the use of recipient structures to allow for random content
encryption keys to be used..  COSE_encrypted is used when the a
recipient structure is not needed because the key to be used is known
implicitly.
COSE supports two different encryption structures.  OOSE_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_encrypted is used when the a
recipient structure is not needed because the key to be used is known
implicitly.
This parameter is used to restrict the algorithms that are to be
used with this key.  If this parameter is present in the key
structure, the application MUST verify that this algorithm matches
the algorithm for which the key is being used.  If the algorthms
do not match, then this key object MUST NOT be used to perform the
cryptographic operation.  Note that the same key can be in a
different key structure with a different or no algorithm
specified, however this is considered to be a poor security
practice.
This parameter is used to restrict the algorithms that are to be
used with this key.  If this parameter is present in the key
structure, the application MUST verify that this algorithm matches
the algorithm for which the key is being used.  If the algorithms
do not match, then this key object MUST NOT be used to perform the
cryptographic operation.  Note that the same key can be in a
different key structure with a different or no algorithm
specified, however this is considered to be a poor security
practice.
The second is a signature with message recovery.  (An example of such
an algorithm is PVSig.)  In this structure, the message content is
processed, but part of is included in the signature.  Moving bytes of
the message content into the signature allows for an effectively
smaller signature, the signature size is still potentially large, but
the message content is shrunk.  This has implications for systems
implementing these algoritms and for applications that use them.  The
first is that the message content is not fully available until after
a signature has been validated.  Until that point the part of the
message contained inside of the signature is unrecoverable.  The
second is that the security analysis of the strength of the signature
is very much based on the structure of the message content.  Messages
which are highly predictable require additional randomness to be
supplied as part of the signature process, in the worst case it
becomes the same as doing a signature with appendix.  Thirdly, in the
event that multple signatures are applied to a message, all of the
signature algorithms are going to be required to consume the same
number of bytes of message content.
The second is a signature with message recovery.  (An example of such
an algorithm is PVSig.)  In this structure, the message content is
processed, but part of is included in the signature.  Moving bytes of
the message content into the signature allows for an effectively
smaller signature, the signature size is still potentially large, but
the message content is shrunk.  This has implications for systems
implementing these algorithms and for applications that use them.
The first is that the message content is not fully available until
after a signature has been validated.  Until that point the part of
the message contained inside of the signature is unrecoverable.  The
second is that the security analysis of the strength of the signature
is very much based on the structure of the message content.  Messages
which are highly predictable require additional randomness to be
supplied as part of the signature process, in the worst case it
becomes the same as doing a signature with appendix.  Thirdly, in the
event that multiple signatures are applied to a message, all of the
signature algorithms are going to be required to consume the same
number of bytes of message content.
System which have poor random number generation can leak their keys
by signing two different messages with the same value of 'k'.
RFC6979 provides a method to deal with this problem by making 'k' be
deterministic based on the message content rather than randomly
generated.  Applications which specify ECDSA should evaluate the
ability to get good random number generation and require this when it
is not possible.  Note: Use of this technique a good idea even when
good random number generation exists.  Doing so both reduces the
possiblity of having the same value of 'k' in two signature
operations, but allows for reproducable signature values which helps
testing.
System which have poor random number generation can leak their keys
by signing two different messages with the same value of 'k'.
RFC6979 provides a method to deal with this problem by making 'k' be
deterministic based on the message content rather than randomly
generated.  Applications which specify ECDSA should evaluate the
ability to get good random number generation and require this when it
is not possible.  Note: Use of this technique a good idea even when
good random number generation exists.  Doing so both reduces the
possibility of having the same value of 'k' in two signature
operations, but allows for reproducible signature values which helps
testing.
Changing the curve used to validate the signature: If one changes
the curve used to validate the signature, then potentially one
could have a two messages with the same signature each computed
under a different curve.  The only requirement on the new curve is
that it's order be the same as the old one and it be acceptable to
the client.  An example would be to change from using the curve
secp256r1 (aka P-256) to using secp256k1.  (Both are 256 bit
curves.)  We current do not have any way to deal with this version
of the attack except to restrict the overall set of curves that
can be used.
Changing the curve used to validate the signature: If one changes
the curve used to validate the signature, then potentially one
could have a two messages with the same signature each computed
under a different curve.  The only requirement on the new curve is
that its order be the same as the old one and it be acceptable to
the client.  An example would be to change from using the curve
secp256r1 (aka P-256) to using secp256k1.  (Both are 256 bit
curves.)  We current do not have any way to deal with this version
of the attack except to restrict the overall set of curves that
can be used.
The RSASSA-PSS signature algorithm is parametized with a hash
function (h), a mask generation function (mgf) and a salt length
(sLen).  For this specification, the mask generation function is
fixed to be MGF1 as defined in RFC3447.  It has been recommended that
the same hash function be used for hashing the data as well as in the
mask generation function, for this specification we following this
recommendation.  The salt length is the same length as the hash
function output.
The RSASSA-PSS signature algorithm is parameterized with a hash
function (h), a mask generation function (mgf) and a salt length
(sLen).  For this specification, the mask generation function is
fixed to be MGF1 as defined in RFC3447.  It has been recommended that
the same hash function be used for hashing the data as well as in the
mask generation function, for this specification we following this
recommendation.  The salt length is the same length as the hash
function output.
Content Encryption Algorithms provide data confidentialty for
potentially large blocks of data using a symmetric key.  They provide
either no or very limited data origination.  (One cannot, for
example, be used to prove the identity of the sender to a third
party.)  The ability to provide data origination is linked to how the
symmetric key is obtained.
Content Encryption Algorithms provide data confidentiality for
potentially large blocks of data using a symmetric key.  They provide
either no or very limited data origination.  (One cannot, for
example, be used to prove the identity of the sender to a third
party.)  The ability to provide data origination is linked to how the
symmetric key is obtained.
The total amount of data encrypted MUST NOT exceed 2^39 - 256 bits
.  An explicit check is required only in environments where it is
expected that it might be exceeded.
Counter with CBC-MAC (CCM) is a generic authentication encryption
block cipher mode defined in RFC3610.  The CCM mode is combined with
the AES block encryption algorithm to define a commonly used content
encryption algorithm used in constrainted devices.
The CCM mode has two parameter choices.  The first choice is M, the
size of the authentication field.  The choice of the value for M
involves a trade-off between message expansion and the probably that
an attacker can undetecably modify a message.  The second choice is
L, the size of the length field.  This value requires a trade-off
between the maximum message size and the size of the Nonce.
The total amount of data encrypted MUST NOT exceed 2^39 - 256
bits.  An explicit check is required only in environments where it
is expected that it might be exceeded.
Counter with CBC-MAC (CCM) is a generic authentication encryption
block cipher mode defined in RFC3610.  The CCM mode is combined with
the AES block encryption algorithm to define a commonly used content
encryption algorithm used in constrained devices.
The CCM mode has two parameter choices.  The first choice is M, the
size of the authentication field.  The choice of the value for M
involves a trade-off between message expansion and the probably that
an attacker can undetectably modify a message.  The second choice is
L, the size of the length field.  This value requires a trade-off
between the maximum message size and the size of the Nonce.
limits messages to 2^16 bytes (64Kbyte) in length.  This
sufficently long for messages in the constrainted world.  The
nonce length is 13 bytes allowing for 2^(13*8) possible values of
the nonce without repeating.
limits messages to 2^64 byes in length.  The nonce length is 7
bytes allowing for 2^56 possible values of the nonce without
repeating.
limits messages to 2^16 bytes (64 KiB) in length.  This
sufficiently long for messages in the constrained world.  The
nonce length is 13 bytes allowing for 2^(13*8) possible values of
the nonce without repeating.
limits messages to 2^64 bytes in length.  The nonce length is 7
bytes allowing for 2^56 possible values of the nonce without
repeating.
The traditional way of sending EC curves has been to send either both
the x and y coordinates, or the x coordinate and a sign bit for the y
coordinate.  The latter encoding has not been recommend in the IETF
due to potential IPR issues with Certicom.  However, for operations
in constrained environments, the ability to shrink a message by not
sending the y coordinate is potentially useful.
The traditional way of sending EC curves has been to send either both
the x and y coordinates, or the x coordinate and a sign bit for the y
coordinate.  The latter encoding has not been recommended in the IETF
due to potential IPR issues.  However, for operations in constrained
environments, the ability to shrink a message by not sending the y
coordinate is potentially useful.
It is requested that IANA assign the following tags from the "Concise
Binary Object Representation (CBOR) Tags" registry.  It is requested
that the tags be assigned in the 24 to 128 value range.
It is requested that IANA assign the following tags from the "Concise
Binary Object Representation (CBOR) Tags" registry.  It is requested
that the tags be assigned in the 24 to 255 value range.