Draft: draft-ietf-cose-msg

Commentary:  not used in enough locations - counter signatures suffer because of this but the group did not care .
This parameter provides the time the content cryptographic
operation is performed.  For signatures and recipient structures,
this would be the time that the signature or recipient key object
was created.  For content structures, this would be the time that
the content structure was created.  The unsigned integer value is
the number of seconds, excluding leap seconds, after midnight UTC,
January 1, 1970.  The field is primarily intended to be to be used
for counter signatures, however it can additionally be used for
replay detection as well.
The signature structure allows for one or more signatures to be
applied to a message payload.  There are provisions for parameters
about the content and parameters about the signature to be carried
along with the signature itself.  These parameters may be
authenticated by the signature, or just present.  An example of a
parameter about the content is the content type.  Examples of
parameters about the signature would be the algorithm and key used to
create the signature, when the signature was created, and counter
signatures.
The signature structure allows for one or more signatures to be
applied to a message payload.  There are provisions for parameters
about the content and parameters about the signature to be carried
along with the signature itself.  These parameters may be
authenticated by the signature, or just present.  An example of a
parameter about the content is the content type.  Examples of
parameters about the signature would be the algorithm and key used to
create the signature and counter signatures.
COSE supports two different encryption structures.  COSE_Encrypted is
used when a recipient structure is not needed because the key to be
used is known implicitly.  COSE_Enveloped is used the rest of time
time.  This includes cases where there are multiple recipients, a
recipient algorithm other than direct is to be used, or the key to be
used is not known.
COSE supports two different encryption structures.  COSE_Encrypted is
used when a recipient structure is not needed because the key to be
used is known implicitly.  COSE_Enveloped is used the rest of time.
This includes cases where there are multiple recipients, a recipient
algorithm other than direct is to be used, or the key to be used is
not known.
I-D.irtf-cfrg-eddsa describes the elliptic curve signature scheme
Edwards-curve Digital Signature Algorithm (EdDSA).  In that document,
the signature algorithm is instantiated using parameters for
edwards25519 and edwards448 curves.  The document additionally
describes two variants of the EdDSA algorithm: Pure EdDSA, where no
hash function is applied to the content before signing and, HashEdDSA
where a hash function is applied to the content before signing and
the result of that hash function is signed.  For use with COSE, on
the pure EdDSA version is used.  This is because it is not expected
that extremely large contents are going to be needed and, based on
the arrangement of the message structure, the entire message is going
to need to be held in memory in order to create or verify a
signature.  Thus, the use of an incremental update process would not
be useful.  Applications can provide the same features by defining
the content of the message as a hash value and transporting the COSE
message and the content as separate items.
The algorithms defined in this document can be found in table-eddsa-
algs.  A single signature algorithm is defined which can be used for
multiple curves.
I-D.irtf-cfrg-eddsa describes the method of encoding the signature
value.
The 'kty' field MUST be present and it MUST be 'OKP'.
The 'crv' field MUST be present, and it MUST be a curve defined
for this signature algorithm.
If the 'alg' field is present, it MUST match 'EdDSA'.
If the 'key_ops' field is present, it MUST include 'sign' when
creating an EdDSA signature.
If the 'key_ops' field is present, it MUST include 'verify' when
verifying an EdDSA signature.
The mathematics for Elliptic Curve Diffie-Hellman can be found in
RFC6090.
The mathematics for Elliptic Curve Diffie-Hellman can be found in
RFC6090.  In this document the algorithm is extended to be used with
the two curves defined in I-D.irtf-cfrg-curves.
The 'kty' field MUST be present and it MUST be 'EC2'.
The 'kty' field MUST be present and it MUST be 'EC2' or 'OKP'.
A new key type is defined for Octet Key Pairs (OKP).  Do not assume
that keys using this type are elliptic curves.  This key type could
be used for other curve types (for example mathematics based on
hyper-elliptic surfaces).
contains an identifier of the curve to be used with the key.
[CREF2] The curves defined in this document for this key type can
be found in table-ec-curves.  Other curves may be registered in
the future and private curves can be used as well.
contains the x coordinate for the EC point.  The octet string
represents a little-endian encoding of x.
contains the private key.
For public keys, it is REQUIRED that 'crv' and 'x' be present in the
structure.  For private keys, it is REQUIRED that 'crv' and 'd' be
present in the structure.  For private keys, it is RECOMMENDED that
'x' also be present, but it can be recomputed from the required
elements and omitting it saves on space.
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 RFC6982.  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 RFC6982, "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".
Description: A JAVA library version of the COSE message
specification.  The cryptography for the library is the Bouncy
Castle JAVA implementation.
Description: A C library version of the COSE message
specification.  The cryptography for the library is currently
OPENSSL version 1.0.
Coverage: The library does not currently implement counter
signatures.  The library includes some self testing both
internally and againist the examples library.
Description: A C# library version of the COSE message
specification.  The cryptography for the library is the Bouncy
Castle C# implementation.
Description: A set of tests for the COSE library is provided as
part of the implementation effort.  Both success and fail tests
has been provided.  All of the examples in this document are are
part of this example set.
Coverage: The attempt has been to have test cases for every
message type and algorithm in the document.  Current examples
dealing with counter signatures, EdDSA and ECDH with Curve24459
and Goldilocks are missing.