Draft: draft-ietf-cose-x509

Commentary: Deal with WGLC comments from various people .
Some of the constrained device situations are being used where an
X.509 PKI is already installed.  One of these situations is the 6tish
environment for enrollment of devices where the certificates are
installed at the factory.  The I-D.selander-ace-cose-ecdhe draft was
also written with the idea that long term certificates could be used
to provide for authentication of devices and uses them to establish
session keys.  A final scenario is the use of COSE as a messaging
application where long term existence of keys can be used along with
a central authentication authority.  The use of certificates in this
scenario allows for key management to be used which is well
understood.
Example COSE messages for the various headers defined below can be
found at https://github.com/cose-wg/Examples.  THIS IS NOT YET DONE
BUT SHOULD BE COMING NOT LONG AFTER THE F2F MEETING.
Some of the constrained device situations are being used where an
X.509 PKI is already installed.  One of these situations is the
6TiSCH environment for enrollment of devices where the certificates
are installed at the factory.  The I-D.selander-ace-cose-ecdhe draft
was also written with the idea that long term certificates could be
used to provide for authentication of devices and uses them to
establish session keys.  A final scenario is the use of COSE as a
messaging application where long term existence of keys can be used
along with a central authentication authority.  The use of
certificates in this scenario allows for key management to be used
which is well understood.
Example COSE messages for the various headers defined below can be
found at https://github.com/cose-wg/Examples.
IANA is requested to register the new COSE Header items in Tags in
the "COSE Header Parameters" registry.
IANA is requested to register the new COSE Header items in Tags2 in
the "COSE Header Algorithm Parameters" registry.
IANA is requested to register the new COSE Header items in Tags in
the "COSE Header Parameters" registry.  The "Value Registry" field is
empty for all of the items.  For each item, the 'Reference' field
points to this document.
IANA is requested to register the new COSE Header items in Tags2 in
the "COSE Header Algorithm Parameters" registry.  For each item, the
'Reference' field points to this document.
The CBOR Object Signing and Encryption (COSE) syntax does not define
any direct methods for the use of hash algorithms.  It also does not
define a structure syntax that is used to encode a digested object
structure along the lines of the DigestedData ASN.1 structure in
RFC5652.  This omission was intentional as a structure consisting of
just a digest identifier, the content, and a digest value does not by
itself provide any strong security service.  Additionally, an
application is going to be better off defining this type of structure
so that it can include add any additional data that needs to be
hashed, as well as methods of obtaining the data.
The CBOR Object Signing and Encryption (COSE) syntax does not define
any direct methods for the use of hash algorithms.  It also does not
define a structure syntax that is used to encode a digested object
structure along the lines of the DigestedData ASN.1 structure in
RFC5652.  This omission was intentional as a structure consisting of
just a digest identifier, the content, and a digest value does not by
itself provide any strong security service.  Additionally, an
application is going to be better off defining this type of structure
so that it can include any additional data that needs to be hashed,
as well as methods of obtaining the data.
Indirect signing of content is a paradigm where the content is not
directly signed, but instead a hash of the content is computed and
that hash value, along with the hash algorithm, is included in the
content that will be signed.  Doing indirect signing allows for the a
signature to be validated without first downloading all of the
content associated with the signature.  This capability can be of
even grater importance in a constrained environment as not all of the
content signed may be needed by the device.
Indirect signing of content is a paradigm where the content is not
directly signed, but instead a hash of the content is computed and
that hash value, along with the hash algorithm, is included in the
content that will be signed.  Doing indirect signing allows for a
signature to be validated without first downloading all of the
content associated with the signature.  This capability can be of
even greater importance in a constrained environment as not all of
the content signed may be needed by the device.
RFC Editor: Please remove this section before publishing.
This document contains some hash functions that are not designed to
be used for cryptographic operations.  An application that is using a
hash function needs to carefully evaluate exactly what hash
properties are needed and which hash functions are going to provide
them.  Applications should also make sure that the ability to change
hash functions is part of the base design as cryptographic advances
are sure to reduce strength of a hash function.
A hash function is a map from a large bit string to a smaller bit
string.  There are going to be collisions by a hash function, the
trick is to make sure that it is difficult to find two values that
are going to map to the same output value.  The standard "Collision
Attack" is one where an attacker can find two different messages that
have the same hash value.  If a collision attack exists, then the
function SHOULD NOT be used for a cryptographic purpose.  The only
reason why such a hash function is used is when there is absolutely
no other choice (e.g. a HSM that cannot be replaced), and only after
looking at the possible security issues.  Cryptographic purposes
would include creation of signatures or the use of hashes for
indirect signatures.  These functions may still be usable for non-
cryptographic purposes.
This document contains some hash functions that are not designed to
be used for cryptographic operations.  An application that is using a
hash function needs to carefully evaluate exactly what hash
properties are needed and which hash functions are going to provide
them.  Applications should also make sure that the ability to change
hash functions is part of the base design as cryptographic advances
are sure to reduce the strength of a hash function.
A hash function is a map from one, normally large, bit string to a
second, usually smaller, bit string.  There are going to be
collisions by a hash function, the trick is to make sure that it is
difficult to find two values that are going to map to the same output
value.  The standard "Collision Attack" is one where an attacker can
find two different messages that have the same hash value.  If a
collision attack exists, then the function SHOULD NOT be used for a
cryptographic purpose.  The only reason why such a hash function is
used is when there is absolutely no other choice (e.g. a Hardware
Security Module (HSM) that cannot be replaced), and only after
looking at the possible security issues.  Cryptographic purposes
would include the creation of signatures or the use of hashes for
indirect signatures.  These functions may still be usable for non-
cryptographic purposes.
An example of a structure which permits all of the above fields to
exist would look like the following.  There is no definition here of
what goes into the 'any' value and how it would be included in the
computed hash value.
An example of a structure which permits all of the above fields to
exist would look like the following.
The family of SHA-2 hash algorithms FIPS-180-4 was designed by the
United States National Security Agency and published in 2001.  Since
that time some additional algorithms have been added to the original
set to deal with length extension attacks and some performance
issues.  While the SHA-3 hash algorithms has been published since
that time, the SHA-2 algorithms are still broadly used.
The family of SHA-2 hash algorithms FIPS-180-4 was designed by the
United States National Security Agency and published in 2001.  Since
that time some additional algorithms have been added to the original
set to deal with length extension attacks and some performance
issues.  While the SHA-3 hash algorithms have been published since
that time, the SHA-2 algorithms are still broadly used.
The family SHA-3 hash algorithms FIPS-180-4 was the result of a
competition run by NIST.  The pair of algorithms known as SHAKE-128
and SHAKE-256 are the instances of SHA-3 that are currently being
standardized in the IETF.
The family SHA-3 hash algorithms FIPS-202 was the result of a
competition run by NIST.  The pair of algorithms known as SHAKE-128
and SHAKE-256 are the instances of SHA-3 that are currently being
standardized in the IETF.
Unlike the SHA-2 hash functions, no algorithm identifier is created
for shorter lengths.  Applications can specify what the minimum
length for a hash function for the protocol.  A validator can infer
the actual length from the hash value in these cases.
Unlike the SHA-2 hash functions, no algorithm identifier is created
for shorter lengths.  Applications can specify a minimum length for
any hash function.  A validator can infer the actual length from the
hash value in these cases.