Draft: draft-ietf-cose-msg

Commentary: Wording and grammar nits in -06 , including corrections to missing words , run - on sentences , commas , hyphenation , and which / that usage . 
 I pulled out of order - you need to resolve the conflict . 
 You should be able to do the merge now . From :   [ ] Sent : Tuesday , November 03 , 2015 12:57 PM To : cose - wg / cose - spec Cc :   Subject : Re : [ cose - spec ]  and wording corrections to -06 ( ) I pulled out of order - you need to resolve the conflict . — Reply to this email directly or view it on
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 specifies how to do signatures, message
authentication codes and encryption using this data format.
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 specifies how to perform signatures, message
authentication codes, and encryption and how to represent
cryptographic keys using this data format.
This parameter one of the ways that can be used to find the key to
be used.  The value of this parameter is matched against the 'kid'
member in a COSE_Key structure.  Applications MUST NOT assume that
'kid' values are unique.  There may be more than one key with the
same 'kid' value, it may be required that all of the keys need to
be checked to find the correct one.  The internal structure of
'kid' values is not defined and generally cannot be relied on by
applications.  Key identifier values are hints about which key to
use, they are not directly a security critical field, for this
reason they can be placed in the unprotected headers bucket.
This parameter one of the ways that can be used to find the key to
be used.  The value of this parameter is matched against the 'kid'
member in a COSE_Key structure.  Applications MUST NOT assume that
'kid' values are unique.  There may be more than one key with the
same 'kid' value, it may be required that all of the keys need to
be checked to find the correct one.  The internal structure of
'kid' values is not defined and generally cannot be relied on by
applications.  Key identifier values are hints about which key to
use.  They are not directly a security critical field.  For this
reason, they can be placed in the unprotected headers 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_encryptedData, 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_encryptedData, 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.
In COSE, the same techniques and structures 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.
In COSE, 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.
contains the encrypted key encoded as a bstr.  If there is not an
encrypted key, then this field is encoded as a nil type.
contains the encrypted key encoded as a bstr.  If there is not an
encrypted key, then this field is encoded as a nil value.
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.
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.
The ECDSA signature algorithm is parameterized with a hash function
(h).  In the event that the length of the hash function output is
greater than group of the key, the left most bytes of the hash output
are used.
The ECDSA signature algorithm is parameterized with a hash function
(h).  In the event that the length of the hash function output is
greater than the group of the key, the left-most bytes of the hash
output are used.
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.
Systems that 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 that 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.
There are two substitution that can theoretically be mounted against
the ECDSA signature algorithm.
There are two substitutions that can theoretically be mounted against
the ECDSA signature algorithm.
The HMAC algorithm is parameterized by an inner and outer padding, a
hash function (h) and an authentication tag value length.  For this
specification, the inner and outer padding are fixed to the values
set in RFC2104.  The length of the authentication tag corresponds to
the difficulty of producing a forgery.  For use in constrained
environments, we define a set of HMAC algorithms that are truncated.
There are currently no known issues when truncating, however the
security strength of the message tag is correspondingly reduced in
strength.  When truncating, the left most tag length bits are kept
and transmitted.
Some recipient algorithms carry the key while others derive a key
from secret data.  For those algorithms which carry the key (i.e.
RSA-OAEP and AES-KeyWrap), the size of the HMAC key SHOULD be the
same size as the underlying hash function.  For those algorithms
which derive the key, the derived key MUST be the same size as the
underlying hash function.
If the key obtained from a key structure, the key type MUST be
'Symmetric'.  Implementations creating and validating MAC values MUST
validate that the key type, key length and algorithm are correct and
appropriate for the entities involved.
HMAC has proved to be resistant even when used with weakening 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.
The HMAC algorithm is parameterized by an inner and outer padding, a
hash function (h) and an authentication tag value length.  For this
specification, the inner and outer padding are fixed to the values
set in RFC2104.  The length of the authentication tag corresponds to
the difficulty of producing a forgery.  For use in constrained
environments, we define a set of HMAC algorithms that are truncated.
There are currently no known issues when truncating, however the
security strength of the message tag is correspondingly reduced in
strength.  When truncating, the left-most tag length bits are kept
and transmitted.
Some recipient algorithms carry the key while others derive a key
from secret data.  For those algorithms that carry the key (i.e.
RSA-OAEP and AES-KeyWrap), the size of the HMAC key SHOULD be the
same size as the underlying hash function.  For those algorithms that
derive the key, the derived key MUST be the same size as the
underlying hash function.
If the key is obtained from a key structure, the key type MUST be
'Symmetric'.  Implementations creating and validating MAC values MUST
validate that the key type, key length, and algorithm are correct and
appropriate for the entities involved.
HMAC has proved to be resistant to attack even when used with
weakening 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.
The GCM mode is parameterized with by the size of the authentication
tag.  The size of the authentication tag is limited to a small set of
values.  For this document however, the size of the authentication
tag is fixed at 128-bits.
The GCM mode is parameterized with by the size of the authentication
tag.  The size of the authentication tag is limited to a small set of
values.  For this document however, the size of the authentication
tag is fixed at 128 bits.
It is unfortunate that the specification for CCM specified L and M as
a count of bytes rather than a count of bits.  This leads to possible
misunderstandings where AES-CCM-8 is frequently used to refer to a
version of CCM mode where the size of the authentication is 64-bits
and not 8-bits.  These values have traditionally been specified as
bit counts rather than byte counts.  This document will follow the
tradition of using bit counts so that it is easier to compare the
different algorithms presented in this document.
It is unfortunate that the specification for CCM specified L and M as
a count of bytes rather than a count of bits.  This leads to possible
misunderstandings where AES-CCM-8 is frequently used to refer to a
version of CCM mode where the size of the authentication is 64 bits
and not 8 bits.  These values have traditionally been specified as
bit counts rather than byte counts.  This document will follow the
tradition of using bit counts so that it is easier to compare the
different algorithms presented in this document.
ChaCha20 and Poly1305 combined together is a new AEAD mode that is
defined in RFC7539.  This is a new algorithm defined to be a cipher
which is not AES and thus would not suffer from any future weaknesses
found in AES.  These cryptographic functions are designed to be fast
in software only implementations.
ChaCha20 and Poly1305 combined together is a new AEAD mode that is
defined in RFC7539.  This is a new algorithm defined to be a cipher
that is not AES and thus would not suffer from any future weaknesses
found in AES.  These cryptographic functions are designed to be fast
in software-only implementations.
Secrets which are uniformly random: This is the type of secret
which is created by a good random number generator.
Secrets which are not uniformly random: This is type of secret
which is created by operations like key agreement.
Secrets which are not random: This is the type of secret that
people generate for things like passwords.
Secrets that are uniformly random: This is the type of secret
which is created by a good random number generator.
Secrets that are not uniformly random: This is type of secret
which is created by operations like key agreement.
Secrets that are not random: This is the type of secret that
people generate for things like passwords.
The algorithms defined in this document are found in table-hkdf.
Recipient algorithms can be defined into a number of different
classes.  COSE has the ability to support many classes of recipient
algorithms.  In this section, a number of classes are listed and then
a set of algorithms are specified for each of the classes.  The names
of the recipient algorithm classes used here are the same as are
defined in RFC7517.  Other specifications use different terms for the
recipient algorithm classes or do not support some of our recipient
algorithm classes.
Recipient algorithms can be defined into a number of different
classes.  COSE has the ability to support many classes of recipient
algorithms.  In this section, a number of classes are listed and then
a set of algorithms are specified for each of the classes.  The names
of the recipient algorithm classes used here are the same as are
defined in RFC7516.  Other specifications use different terms for the
recipient algorithm classes or do not support some of our recipient
algorithm classes.
These recipient algorithms take a common shared secret between the
two parties and applies the HKDF function (HKDF) using the context
structure defined in context to transform the shared secret into the
necessary key.  Either the 'salt' parameter of HKDF or the partyU
'nonce' parameter of the context structure MUST be present.  This
parameter can be generated either randomly or deterministically, the
requirement is that it be a unique value for the key pair in
question.
These recipient algorithms take a common shared secret between the
two parties and applies the HKDF function (HKDF) using the context
structure defined in context to transform the shared secret into the
necessary key.  Either the 'salt' parameter of HKDF or the partyU
'nonce' parameter of the context structure MUST be present.  This
parameter can be generated either randomly or deterministically.  The
requirement is that it be a unique value for the key pair in
question.
The shared secret need to have some method to be regularly updated
over time.  The shared secret is forming the basis of trust, although
not used directly it should still be subject to scheduled rotation.
The shared secret needs to have some method to be regularly updated
over time.  The shared secret forms the basis of trust.  Although not
used directly, it should still be subject to scheduled rotation.
The AES Key Wrapping algorithm is defined in RFC3394.  This algorithm
uses an AES key to wrap a value that is a multiple of 64-bits, as
such it can be used to wrap a key for any of the content encryption
algorithms defined in this document.  The algorithm requires a single
fixed parameter, the initial value.  This is fixed to the value
specified in Section 2.2.3.1 of RFC3394.  There are no public
parameters that vary on a per invocation basis.
The AES Key Wrapping algorithm is defined in RFC3394.  This algorithm
uses an AES key to wrap a value that is a multiple of 64 bits.  As
such, it can be used to wrap a key for any of the content encryption
algorithms defined in this document.  The algorithm requires a single
fixed parameter, the initial value.  This is fixed to the value
specified in Section 2.2.3.1 of RFC3394.  There are no public
parameters that vary on a per invocation basis.
The most commonly used key agreement algorithm used is Diffie-
Hellman, but other variants exist.  Since COSE is designed for a
store and forward environment rather than an on-line environment,
many of the DH variants cannot be used as the receiver of the message
cannot provide any key material.  One side-effect of this is that
perfect forward security is not achievable, a static key will always
be used for the receiver of the COSE message.
The most commonly used key agreement algorithm used is Diffie-
Hellman, but other variants exist.  Since COSE is designed for a
store and forward environment rather than an on-line environment,
many of the DH variants cannot be used as the receiver of the message
cannot provide any key material.  One side-effect of this is that
perfect forward security is not achievable.  A static key will always
be used for the receiver of the COSE message.
Static-Static DH: where a static key is used for both the sender
and the recipient.  The use of static keys allows for recipient to
get a weak version of data origination for the message.  When
static-static key agreement is used, then some piece of unique
data is required to ensure that a different key is created for
each message.
Curve Type/Curve: The curve selected controls not only the size of
the shared secret, but the mathematics for computing the shared
secret.  The curve selected also controls how a point in the curve
is represented and what happens for the identity points on the
curve.  In this specification we allow for a number of different
curves to be used.  The curves are defined in table-ec-curves.
Since the only the math is changed by changing the curve, the
curve is not fixed for any of the algorithm identifiers we define,
instead it is defined by the points used.
Key derivation algorithm: The result of an ECDH key agreement
process does not provide a uniformly random secret, as such it
needs to be run through a KDF in order to produce a usable key.
Processing the secret through a KDF also allows for the
introduction of both context material, how the key is going to be
used, and one time material in the even to of a static-static key
agreement.
Curve Type/Curve: The curve selected controls not only the size of
the shared secret, but the mathematics for computing the shared
secret.  The curve selected also controls how a point in the curve
is represented and what happens for the identity points on the
curve.  In this specification, we allow for a number of different
curves to be used.  The curves are defined in table-ec-curves.
Since the only the math is changed by changing the curve, the
curve is not fixed for any of the algorithm identifiers we define.
Instead, it is defined by the points used.
Key derivation algorithm: The result of an ECDH key agreement
process does not provide a uniformly random secret.  As such, it
needs to be run through a KDF in order to produce a usable key.
Processing the secret through a KDF also allows for the
introduction of both context material, how the key is going to be
used, and one time material in the even to of a static-static key
agreement.
Key Wrap algorithm: The key wrap algorithm can be 'none' if the
result of the KDF is going to be used as the key directly.  This
option, along with static-static, should be used if knowledge
about the sender is desired.  If 'none' is used then the content
layer encryption algorithm size is value fed to the context
structure.  Support is also provided for any of the key wrap
algorithms defined in key_wrap_algs.  If one of these options is
used, the input key size to the key wrap algorithm is the value
fed into the context structure as the key size.
The set of algorithms direct ECDH defined in this document are found
in table-ecdh-es-table.
This document defines these algorithms to be used with the curves
P-256, P-384, P-521.  Implementations MUST verify that the key type
and curve are correct, different curves are restricted to different
key types.  Implementations MUST verify that the curve and algorithm
are appropriate for the entities involved.
Key Wrap algorithm: The key wrap algorithm can be 'none' if the
result of the KDF is going to be used as the key directly.  This
option, along with static-static, should be used if knowledge
about the sender is desired.  If 'none' is used, then the content
layer encryption algorithm size is value fed to the context
structure.  Support is also provided for any of the key wrap
algorithms defined in key_wrap_algs.  If one of these options is
used, the input key size to the key wrap algorithm is the value
fed into the context structure as the key size.
The set of direct ECDH algorithms defined in this document are found
in table-ecdh-es-table.
This document defines these algorithms to be used with the curves
P-256, P-384, P-521.  Implementations MUST verify that the key type
and curve are correct.  Different curves are restricted to different
key types.  Implementations MUST verify that the curve and algorithm
are appropriate for the entities involved.
The COSE_Key object defines a way to hold a single key object, it is
still required that the members of individual key types be defined.
This section of the document is where we define an initial set of
members for specific key types.
The COSE_Key object defines a way to hold a single key object.  It is
still required that the members of individual key types be defined.
This section of the document is where we define an initial set of
members for specific key types.
For each of the key types, we define both public and private members.
The public members are what is transmitted to others for their usage.
We define private members mainly for the purpose of archival of keys
by individuals.  However, there are some circumstances where private
keys may be distributed by various entities in a protocol.  Examples
include: Entities which have poor random number generation.
Centralized key creation for multi-cast type operations.  Protocols
where a shared secret is used as a bearer token for authorization
purposes.
Key types are identified by the 'kty' member of the COSE_Key object.
In this document we define four values for the member.
For each of the key types, we define both public and private members.
The public members are what is transmitted to others for their usage.
We define private members mainly for the purpose of archival of keys
by individuals.  However, there are some circumstances in which
private keys may be distributed by various entities in a protocol.
Examples include: entities that have poor random number generation,
centralized key creation for multi-cast type operations, and
protocols in which a shared secret is used as a bearer token for
authorization purposes.
Two different key structures could be defined for Elliptic Curve
keys.  One version uses both an x and a y coordinate, potentially
with point compression.  This is the traditional EC point
representation that is used in RFC5480.  The other version uses only
the x coordinate as the y coordinate is either to be recomputed or
not needed for the key agreement operation Currently no algorithms
are defined using this key structure.
Two different key structures could be defined for Elliptic Curve
keys.  One version uses both an x and a y coordinate, potentially
with point compression.  This is the traditional EC point
representation that is used in RFC5480.  The other version uses only
the x coordinate as the y coordinate is either to be recomputed or
not needed for the key agreement operation.  Currently no algorithms
are defined using this key structure.
This is the value used for the label.  The label can be either an
integer or a string.  Registration in the table is based on the
value of the label requested.  Integer values between 1 and 255
and strings of length 1 are designated as Standards Track Document
required.  Integer values from 256 to 65535 and strings of length
2 are designated as Specification Required.  Integer values of
greater than 65535 and strings of length greater than 2 are
designated as first come first server.  Integer values in the
range -1 to -65536 are delegated to the "COSE Header Algorithm
Label" registry.  Integer values beyond -65536 are marked as
private use.
This is the value used for the label.  The label can be either an
integer or a string.  Registration in the table is based on the
value of the label requested.  Integer values between 1 and 255
and strings of length 1 are designated as Standards Track Document
required.  Integer values from 256 to 65535 and strings of length
2 are designated as Specification Required.  Integer values of
greater than 65535 and strings of length greater than 2 are
designated as first come, first served.  Integer values in the
range -1 to -65536 are delegated to the "COSE Header Algorithm
Label" registry.  Integer values beyond -65536 are marked as
private use.
The initial contents of the registry can be found in:
HKDF_Alg_Params, KDF_Context_Alg_Params, table-ecdh-es-parameter-
table.  The specification column for all rows in that table should be
this document.
The initial contents of the registry can be found in HKDF_Alg_Params,
KDF_Context_Alg_Params, and table-ecdh-es-parameter-table.  The
specification column for all rows in that table should be this
document.
The value to be used to identify this algorithm.  Algorithm values
MUST be unique.  The value can be a positive integer, a negative
integer or a string.  Integer values between 0 and 255 and strings
of length 1 are designated as Standards Track Document required.
Integer values from 256 to 65535 and strings of length 2 are
designated as Specification Required.  Integer values of greater
than 65535 and strings of length greater than 2 are designated as
first come first server.  Integer values in the range -1 to -65536
are delegated to the "COSE Header Algorithm Label" registry.
Integer values beyond -65536 are marked as private use.
The initial contents of the registry can be found in the following:
table-AES-CCM, table-AES-GCM, Table-CHACHA, table_ecdsa, table-hmac,
table-aes-mac, table-direct, table-direct-kdf, table_aes_keywrap,
table-ecdh-es-table.  The specification column for all rows in that
table should be this document.
The value to be used to identify this algorithm.  Algorithm values
MUST be unique.  The value can be a positive integer, a negative
integer or a string.  Integer values between 0 and 255 and strings
of length 1 are designated as Standards Track Document required.
Integer values from 256 to 65535 and strings of length 2 are
designated as Specification Required.  Integer values of greater
than 65535 and strings of length greater than 2 are designated as
first come, first served.  Integer values in the range -1 to
-65536 are delegated to the "COSE Header Algorithm Label"
registry.  Integer values beyond -65536 are marked as private use.
The initial contents of the registry can be found in table-AES-CCM,
table-AES-GCM, Table-CHACHA, table_ecdsa, table-hmac, table-aes-mac,
table-direct, table-direct-kdf, table_aes_keywrap, and table-ecdh-es-
table.  The specification column for all rows in that table should be
this document.
The value to be used to identify this algorithm.  Key map labels
MUST be unique.  The label can be a positive integer, a negative
integer or a string.  Integer values between 0 and 255 and strings
of length 1 are designated as Standards Track Document required.
Integer values from 256 to 65535 and strings of length 2 are
designated as Specification Required.  Integer values of greater
than 65535 and strings of length greater than 2 are designated as
first come first server.  Integer values in the range -1 to -65536
are used for key parameters specific to a single algorithm
delegated to the "COSE Key Parameter Label" registry.  Integer
values beyond -65536 are marked as private use.
The value to be used to identify this algorithm.  Key map labels
MUST be unique.  The label can be a positive integer, a negative
integer or a string.  Integer values between 0 and 255 and strings
of length 1 are designated as Standards Track Document required.
Integer values from 256 to 65535 and strings of length 2 are
designated as Specification Required.  Integer values of greater
than 65535 and strings of length greater than 2 are designated as
first come, first served.  Integer values in the range -1 to
-65536 are used for key parameters specific to a single algorithm
delegated to the "COSE Key Parameter Label" registry.  Integer
values beyond -65536 are marked as private use.
This registry will be initially populated by the values in table-
ec2-keys, and table-symmetric-keys.  The specification column for all
of these entries will be this document.
This registry will be initially populated by the values in table-
ec2-keys and table-symmetric-keys.  The specification column for all
of these entries will be this document.
This is the value used to identify the curve.  These values MUST
be unique.  The integer values from -256 to 255 are designated as
Standards Track Document Required.  The integer values from 256 to
65535 and -65536 to -257 are designated as Specification Required.
Integer values over 65535 are designated as first come first
serve.  Integer values less than -65536 are marked as private use.
This is the value used to identify the curve.  These values MUST
be unique.  The integer values from -256 to 255 are designated as
Standards Track Document Required.  The integer values from 256 to
65535 and -65536 to -257 are designated as Specification Required.
Integer values over 65535 are designated as first come, first
served.  Integer values less than -65536 are marked as private
use.
This section registers the "application/cose+json" and "application/
cose-set+json" media types in the "Media Types" registry.  These
media types are used to indicate, respectively, that content is a
COSE_Key or COSE_KeySet object.
This section registers the "application/cose-key+cbor" and
"application/cose-key-set+cbor" media types in the "Media Types"
registry.  These media types are used to indicate, respectively, that
content is a COSE_Key or COSE_KeySet object.
This section registers a set of content formats for CoAP.  ID
assignment in the 24-255 range requested.
Use of direct key with other recipient structures hands the key to
other recipients.
This section registers a set of content formats for CoAP.  ID
assignment in the 24-255 range is requested.
Protect private keys.
MAC messages with more than one recipient means one cannot figure
out which party sent the message.
Use of a direct key with other recipient structures hands the key
to the other recipients.
Need to verify that: 1) the kty field of the key matches the key
and algorithm being used.  2) the kty field needs to be included
in the trust decision as well as the other key fields.  3) the
algorithm be included in the trust decision.
Need to verify that: 1) the kty field of the key matches the key
and algorithm being used, 2) the kty field needs to be included in
the trust decision as well as the other key fields, and 3) the
algorithm is included in the trust decision.