Draft: draft-ietf-cose-rfc8152bis-struct

Commentary: The set of updates going into things for the -01 release 
 COSESign0 is only mentioned once in the document , but COSESign1 appears many times . 
 Fixed in 
 kty in section 7.1 points to key common parameters and not to the key type registry . 
 Fixed in 
 The restriction applies to the encoding of the COSEKDFContext , Sigstructure , the Encstructure , and the MAC_structure . 
 Fixed in
This document along with I-D.schaad-cose-rfc8152bis-algs obsoletes
RFC8152.
This document along with I-D.ietf-cose-rfc8152bis-algs obsoletes
RFC8152.
This document does not contain the rules and procedures for using
specific cryptographic algorithms.  Details on specific algorithms
can be found in I-D.schaad-cose-rfc8152bis-algs and RFC8230.  Details
for additional algorithms are expected to be defined in future
documents.
This document does not contain the rules and procedures for using
specific cryptographic algorithms.  Details on specific algorithms
can be found in I-D.ietf-cose-rfc8152bis-algs and RFC8230.  Details
for additional algorithms are expected to be defined in future
documents.
This parameter is used to indicate the algorithm used for the
security processing.  This parameter MUST be authenticated where
the ability to do so exists.  This support is provided by AEAD
algorithms or construction (COSE_Sign, COSE_Sign0, COSE_Mac, and
COSE_Mac0).  This authentication can be done either by placing the
parameter in the protected header bucket or as part of the
externally supplied data.  The value is taken from the "COSE
Algorithms" registry (see COSE.Algorithms).
This parameter is used to indicate the algorithm used for the
security processing.  This parameter MUST be authenticated where
the ability to do so exists.  This support is provided by AEAD
algorithms or construction (COSE_Sign, COSE_Sign1, COSE_Mac, and
COSE_Mac0).  This authentication can be done either by placing the
parameter in the protected header bucket or as part of the
externally supplied data.  The value is taken from the "COSE
Algorithms" registry (see COSE.Algorithms).
If multiple items are included, applications need to ensure that
the same byte string cannot produced if there are different
inputs.  This could occur by appending the strings 'AB' and 'CDE'
or by appending the strings 'ABC' and 'DE'.  This is usually
addressed by making fields a fixed width and/or encoding the
length of the field as part of the output.  Using options from
CoAP RFC7252 as an example, these fields use a TLV structure so
they can be concatenated without any problems.
If multiple items are included, applications need to ensure that
the same byte string cannot produced if there are different
inputs.  This would occur by appending the strings 'AB' and 'CDE'
or by appending the strings 'ABC' and 'DE'.  This is usually
addressed by making fields a fixed width and/or encoding the
length of the field as part of the output.  Using options from
CoAP RFC7252 as an example, these fields use a TLV structure so
they can be concatenated without any problems.
The key is determined by the key and algorithm in the recipient
structure.  The encryption algorithm and size of the key to be
used are inputs into the KDF used for the recipient.  (For
direct, the KDF can be thought of as the identity operation.)
Examples of these algorithms are found in Sections !!! DIRECT-
KDF !!!  and !!! ECDH !!!  of I-D.schaad-cose-rfc8152bis-algs.
The key is determined by the key and algorithm in the recipient
structure.  The encryption algorithm and size of the key to be
used are inputs into the KDF used for the recipient.  (For
direct, the KDF can be thought of as the identity operation.)
Examples of these algorithms are found in Sections !!! DIRECT-
KDF !!!  and !!! ECDH !!!  of I-D.ietf-cose-rfc8152bis-algs.
This document defines a set of common parameters for a COSE Key
object.  table-key-labels provides a summary of the parameters
defined in this section.  There are also parameters that are defined
for specific key types.  Key-type-specific parameters can be found in
I-D.schaad-cose-rfc8152bis-algs.
This document defines a set of common parameters for a COSE Key
object.  table-key-labels provides a summary of the parameters
defined in this section.  There are also parameters that are defined
for specific key types.  Key-type-specific parameters can be found in
I-D.ietf-cose-rfc8152bis-algs.
The same KDF can be set up to deal with the first two types of
secrets in a different way.  The KDF defined in !!! HDKF !!! (section
XXXX of I-D.schaad-cose-rfc8152bis-algs) is such a function.  This is
reflected in the set of algorithms defined around the HMAC-based
Extract-and-Expand Key Derivation Function (HKDF).
The same KDF can be set up to deal with the first two types of
secrets in a different way.  The KDF defined in !!! HDKF !!! (section
XXXX of I-D.ietf-cose-rfc8152bis-algs) is such a function.  This is
reflected in the set of algorithms defined around the HMAC-based
Extract-and-Expand Key Derivation Function (HKDF).
Key transport mode is also called key encryption mode in some
standards.  Key transport mode differs from key wrap mode in that it
uses an asymmetric encryption algorithm rather than a symmetric
encryption algorithm to protect the key.  This document does not
define any key transport mode algorithms.
Key transport mode is also called key encryption mode in some
standards.  Key transport mode differs from key wrap mode in that it
uses an asymmetric encryption algorithm rather than a symmetric
encryption algorithm to protect the key.  A set of key transport
algorithms are defined in RFC8230.
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in RFC7942.  The
description of implementations in this section is intended to assist
the IETF in its decision processes in progressing drafts to RFCs.
Please note that the listing of any individual implementation here
does not imply endorsement by the IETF.  Furthermore, no effort has
been spent to verify the information presented here that was supplied
by IETF contributors.  This is not intended as, and must not be
construed to be, a catalog of available implementations or their
features.  Readers are advised to note that other implementations may
exist.
According to RFC7942, "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
There are three different implementations that have been created by
the author of the document both to create the examples that are
included in the document and to validate the structures and
methodology used in the design of COSE.
Languages: There are three different languages that are currently
supported: Java, C# and C.
Cryptography: The Java and C# libraries use Bouncy Castle to
provide the required cryptography.  The C version uses OPENSSL
Version 1.0 for the cryptography.
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.
Testing: All of the examples in the example library are generated
by the C# library and then validated using the Java and C
libraries.  All three libraries have tests to allow for the
creating of the same messages that are in the example library
followed by validating them.  These are not compared against the
example library.  The Java and C# libraries have unit testing
included.  Not all of the MUST statements in the document have
been implemented as part of the libraries.  One such statement is
the requirement that unique labels be present.
Description: A set of tests for the COSE library is provided as
part of the implementation effort.  Both success and fail tests
have been provided.  All of the examples in this document are part
of this example set.
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.