Draft: draft-ietf-cose-rfc8152bis-algs

Commentary: All of the updates for releasing -02 versions of the documents .
In this specification the conventions for the use of a number of
cryptographic algorithms with COSE.  The details of the structure of
COSE are defined in I-D.schaad-cose-rfc8152bis-struct.
This document along with I-D.schaad-cose-rfc8152bis-struct obsoletes
RFC8152.
In this specification the conventions for the use of a number of
cryptographic algorithms with COSE.  The details of the structure of
COSE are defined in I-D.ietf-cose-rfc8152bis-struct.
This document along with I-D.ietf-cose-rfc8152bis-struct obsoletes
RFC8152.
The core COSE specification consists of two documents.  I-D.schaad-
cose-rfc8152bis-struct contains the serialization structures and the
procedures for using the different cryptographic algorithms.  This
document provides for an initial set of algorithms that are then use
with those structures.  Additional algorithms beyond what are in this
document are defined elsewhere.
The core COSE specification consists of two documents.  I-D.ietf-
cose-rfc8152bis-struct contains the serialization structures and the
procedures for using the different cryptographic algorithms.  This
document provides for an initial set of algorithms that are then use
with those structures.  Additional algorithms beyond what are in this
document are defined elsewhere.
Extract the sections dealing with specific algorithms into this
document.  The sections dealing with structure and general
processing rules are placed in I-D.ietf-cose-rfc8152bis-struct.
The document defines signature algorithm identifiers for two
signature algorithms.
A GitHub project has been created at <https://github.com/cose-wg/
Examples> that contains not only the examples presented in this
document, but a more complete set of testing examples as well.  Each
example is found in a JSON file that contains the inputs used to
create the example, some of the intermediate values that can be used
in debugging the example and the output of the example presented in
both a hex and a CBOR diagnostic notation format.  Some of the
examples at the site are designed failure testing cases; these are
clearly marked as such in the JSON file.  If errors in the examples
in this document are found, the examples on GitHub will be updated,
and a note to that effect will be placed in the JSON file.
I-D.ietf-cose-rfc8152bis-struct contains a generic description of
signature algorithms.  The document defines signature algorithm
identifiers for two signature algorithms.
This section defines the usages for two MAC algorithms.
I-D.ietf-cose-rfc8152bis-struct contains a generic description of MAC
algorithms.  This section defines the conventions for two MAC
algorithms.
This document defines the identifier and usages for three content
encryption algorithms.
I-D.ietf-cose-rfc8152bis-struct contains a generic description of
Content Encryption algorithms.  This document defines the identifier
and usages for three content encryption algorithms.
This document defines a single context structure and a single KDF.
These elements are used for all of the recipient algorithms defined
in this document that require a KDF process.  These algorithms are
defined in Sections direct-kdf, ECDH, and ECDH-wrap.
I-D.ietf-cose-rfc8152bis-struct contains a generic description of Key
Derivation Functions.  This document defines a single context
structure and a single KDF.  These elements are used for all of the
recipient algorithms defined in this document that require a KDF
process.  These algorithms are defined in Sections direct-kdf, ECDH,
and ECDH-wrap.
This document defines the identifiers and usage for a number of
content key distribution methods.
I-D.ietf-cose-rfc8152bis-struct contains a generic description of
content key distribution methods.  This document defines the
identifiers and usage for a number of content key distribution
methods.
Direct encryption algorithm is defined in I-D.ietf-cose-rfc8152bis-
struct.  Information about how to fill in the COSE_Recipient
structure are detailed there.
IANA created and populated the "COSE Algorithms" registry as part of
processing processing RFC8152.  IANA is requested to update the for
individual algorithms from RFC8152 to this document.
This document does not modify the guidance for designated experts.
IANA has created a new registry titled "COSE Key Type Parameters".
The registry has been created to use the "Expert Review Required"
registration procedure.  Expert review guidelines are provided in
review.
This field contains a descriptive string of a key type.  This
should be a value that is in the "COSE Key Common Parameters"
registry and is placed in the 'kty' field of a COSE Key structure.
This is a descriptive name that enables easier reference to the
item.  It is not used in the encoding.
The label is to be unique for every value of key type.  The range
of values is from -65536 to -1.  Labels are expected to be reused
for different keys.
This field contains the CBOR type for the field.
This field contains a brief description for the field.
This contains a pointer to the public specification for the field
if one exists.
This registry has been initially populated by the values in Tables
table-ec2-keys, table-ec1-keys, and table-symmetric-keys.  All of the
entries in the "References" column of this registry point to this
document.
IANA has created a new registry titled "COSE Key Types".  The
registry has been created to use the "Expert Review Required"
registration procedure.  Expert review guidelines are provided in
review.
This is a descriptive name that enables easier reference to the
item.  The name MUST be unique.  It is not used in the encoding.
This is the value used to identify the curve.  These values MUST
be unique.  The value can be a positive integer, a negative
integer, or a string.
This field contains a brief description of the curve.
This contains a pointer to the public specification for the curve
if one exists.
This registry has been initially populated by the values in
table_key_types.  The specification column for all of these entries
will be this document.
IANA created and populated the "COSE Elliptic Curves" registry as
part of processing RFC8152.  IANA is requested to change the
reference from RFC8152 to this document for all values in the
registry.
This document does not change the guidance for Designated Experts.
All of the IANA registries established in this document are defined
as expert review.  This section gives some general guidelines for
what the experts should be looking for, but they are being designated
as experts for a reason, so they should be given substantial
latitude.
Point squatting should be discouraged.  Reviewers are encouraged
to get sufficient information for registration requests to ensure
that the usage is not going to duplicate one that is already
registered, and that the point is likely to be used in
deployments.  The zones tagged as private use are intended for
testing purposes and closed environments; code points in other
ranges should not be assigned for testing.
Specifications are required for the standards track range of point
assignment.  Specifications should exist for specification
required ranges, but early assignment before a specification is
available is considered to be permissible.  Specifications are
needed for the first-come, first-serve range if they are expected
to be used outside of closed environments in an interoperable way.
When specifications are not provided, the description provided
needs to have sufficient information to identify what the point is
being used for.
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.
When algorithms are registered, vanity registrations should be
discouraged.  One way to do this is to require registrations to
provide additional documentation on security analysis of the
algorithm.  Another thing that should be considered is requesting
an opinion on the algorithm from the Crypto Forum Research Group
(CFRG).  Algorithms that do not meet the security requirements of
the community and the messages structures should not be
registered.
There are no IANA actions.
Split the orignal document into this document and I-D.ietf-cose-
rfc8152bis-algs.
Add some text describing why there is no digest structure defined
by COSE.
Coverage: The libraries currently do not have full support for
counter signatures of either variety.  They do have support to
allow for implicit algorithm support as they allow for the
application to set attributes that are not to be sent in the
message.
Coverage: The C version currently does not have full countersign
support.  THe other two versions do.  They do have support to
allow for implicit algorithm support as they allow for the
application to set attributes that are not to be sent in the
message.
Coverage: Full Encrypt, Signature and MAC objects are supported.
Testing: Basic testing against the common example library.
Testing: Basic testing plus running against the common example
library.
Coverage: An attempt has been made to have test cases for every
message type and algorithm in the document.  Currently examples
dealing with counter signatures, EdDSA, and ECDH with Curve24459
and Goldilocks are missing.
Coverage: An attempt has been made to have test cases for every
message type and algorithm in the document.  Currently examples
dealing with counter signatures, and ECDH with Curve24459 and
Goldilocks are missing.