Draft: draft-ietf-cose-rfc8152bis-algs

Commentary: Updates from the -03 drop
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.
A GitHub project has been created at <https://github.com/cose-wg/
Examples> that contains a 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.
The signature algorithm results in a pair of integers (R, S).  These
integers will be the same length as the length of the key used for
the signature process.  The signature is encoded by converting the
integers into byte strings of the same length as the key size.  The
length is rounded up to the nearest byte and is left padded with zero
bits to get to the correct length.  The two integers are then
concatenated together to form a byte string that is the resulting
signature.
The signature algorithm results in a pair of integers (R, S).  These
integers will be the same length as the length of the key used for
the signature process.  The signature is encoded by converting the
integers into bit strings of the same length as the key size.  The
length is rounded up to the nearest byte and is left padded with zero
bits to get to the correct length.  The two integers are then
concatenated together to form a byte string that is the resulting
signature.
This limits messages to 2^16 bytes (64 KiB) in length.  This is
sufficiently long for messages in the constrained world.  The
nonce length is 13 bytes allowing for 2^(13*8) possible values of
the nonce without repeating.
This limits messages to 2^16 bytes (64 KiB) in length.  This is
sufficiently long for messages in the constrained world.  The
nonce length is 13 bytes allowing for 2^104 possible values of the
nonce without repeating.
COSE does not have an Ephemeral-Ephemeral version defined.  The
reason for this is that COSE is not an an online protocol by itself
and thus does not have a method to establish ephemeral secrets on
both sides.  The expectation is that a protocol would establish the
secrets for both sides, and then they would be used as static-static
for the purposes of COSE, or that the protocol would generate a
shared secret and a direct encryption would be used.
There are no IANA actions.
The restriction applies to the encoding of the COSE_KDF_Context.
Applications MUST NOT generate messages with the same label used
twice as a key in a single map.  Applications MUST NOT parse and
process messages with the same label used twice as a key in a
single map.  Applications can enforce the parse and process
requirement by using parsers that will fail the parse step or by
using parsers that will pass all keys to the application, and the
application can perform the check for duplicate keys.
There are no IANA actions.  The required actions are in I-D.ietf-
cose-rfc8152bis-struct.
Rearrange the text around counter signatures and define a CBOR Tag
for a standalong countersignature.
The buckets are present in all of the security objects defined in
this document.  The fields in order are the 'protected' bucket (as a
CBOR 'bstr' type) and then the 'unprotected' bucket (as a CBOR 'map'
type).  The presence of both buckets is required.  The parameters
that go into the buckets come from the IANA "COSE Header Parameters"
registry (cose-header-key-table).  Some common parameters are defined
in the next section, but a number of parameters are defined
throughout this document.
The buckets are present in all of the security objects defined in
this document.  The fields in order are the 'protected' bucket (as a
CBOR 'bstr' type) and then the 'unprotected' bucket (as a CBOR 'map'
type).  The presence of both buckets is required.  The parameters
that go into the buckets come from the IANA "COSE Header Parameters"
registry (cose-header-key-table).  Some common parameters are defined
in the next section.
Integer labels in the range of 0 to 8 SHOULD be omitted.
Integer labels in the range of 0 to 7 SHOULD be omitted.
This parameter holds one or more counter signature values.
Counter signatures provide a method of having a second party sign
some data.  The counter signature parameter can occur as an
unprotected attribute in any of the following structures:
COSE_Sign1, COSE_Signature, COSE_Encrypt, COSE_recipient,
COSE_Encrypt0, COSE_Mac, and COSE_Mac0.  These structures all have
the same beginning elements, 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 one or more counter signature values.
Counter signatures provide a method of having a second party sign
some data.  The counter signature parameter can occur as an
unprotected attribute in any of the following structures:
COSE_Sign1, COSE_Signature, COSE_Encrypt, COSE_recipient,
COSE_Encrypt0, COSE_Mac, and COSE_Mac0.  These structures all have
the same beginning elements, so that a consistent calculation of
the counter signature can be computed.  Details on counter
signatures are found in counter_signature.
"CounterSignature0" for signatures used as CounterSignature0
attributes.
The protected attributes from the signer structure encoded in a
bstr type.  If there are no protected attributes, a bstr of length
zero is used.  This field is omitted for the COSE_Sign1 signature
structure.
The protected attributes from the signer structure encoded in a
bstr type.  If there are no protected attributes, a bstr of length
zero is used.  This field is omitted for the COSE_Sign1 signature
structure and CounterSignature0 attributes.
Counter signatures provide a method of associating a different
signature generated by different signers with some piece of content.
This is normally used to provide a signature on a signature allowing
for a proof that a signature existed at a given time (e.g., a
Timestamp).  In this document, we allow for counter signatures to
exist in a greater number of environments.  As an example, it is
possible to place a counter signature in the unprotected attributes
of a COSE_Encrypt object.  This would allow for an intermediary to
either verify that the encrypted byte string has not been modified,
without being able to decrypt it, or assert that an encrypted byte
string either existed at a given time or passed through it in terms
of routing (e.g., a proxy signature).
The creation and validation of counter signatures over the different
items relies on the fact that the objects have the same structure.
The elements are a set of protected attributes, a set of unprotected
attributes, and a body, in that order.  This means that the
Sig_structure can be used in a uniform manner to get the byte string
for processing a signature.  If the counter signature is going to be
computed over a COSE_Encrypt structure, the body_protected and
payload items can be mapped into the Sig_structure in the same manner
as from the COSE_Sign structure.
COSE supports two different forms for counter signatures.  Full
countersignatures use the structure COSE_Countersign.  This is same
structure as COSE_Signature and thus it can have protected
attributes, chained countersignatures and information about
identifying the key.  Abbreviated countersignatures use the structure
COSE_Countersign1.  This structure only contains the signature value
and nothing else.  The structures cannot be converted between each
other; as the signature computation includes a parameter identifying
which structure is being used, the converted structure will fail
signature validation.
COSE was designed for uniformity in how the data strutures are
specified.  One result of this is that for COSE one can expand the
concept of countersignatures beyond just the idea of signing a
signature to being able to sign most of the structures without having
to create a new signing layer.  When creating a countersignature, one
needs to be clear about the security properties that result.  When
done on a COSE_Signature, the normal countersignature semantics are
preserved.  That is the countersignature makes a statement about the
existance of a signature and, when used as a timestamp, a time point
at which the signature exists.  When done on a COSE_Mac or a
COSE_Mac0, one effectively upgrades the MAC operation to a sginature
operation.  When done on a COSE_Encrypt or COSE_Encrypt0, the
existance of the encrypted data is attested to.  It should be noted
that there is a big difference between attesting to the enrypted data
as oppose to attesting to the unencrypted data.  If the latter is
what is desired, then one needs to apply a signature to the data and
then encrypt that.  It is always possible to construct cases where
the decryption is successful, while providing completely different
answers by using a different key.  This situation is not detectable
by a countersignature on the encrypted data.
The COSE_Countersignature structure allows for the same set of
capabilities of a COSE_Signature.  This means that all of the
capabilities of a signature are duplicated with this structure.
Specifically, the countersigner does not need to be related to the
producer of what is being counter signed as key and algorithm
identification can be placed in the countersignature attributes.
This also means that the countersignature can itself be
countersigned.  This is a feature required by protocols such as long-
term archiving services.  More information on how this is used can be
found in the evidence record syntax described in RFC4998.
The details of the fields of a countersignature can be found in full-
signature.  The process of creating and validating abbreviated
countersignatures is defined in Sig_structure.
Abbreviated countersignatures were designed primarily to deal with
the problem of having group encrypted messaging, but still needing to
know who orginated the message.  The object was to keep the
countersignature as small as possible while still providing the
needed security.  For abbreviated countersignatures, there is no
provision for any protected attributes related to the signing
operation.  Instead, the context that was used to describe the
encryption processing is also assumed to describe the context that
was used to create the countersignature.
The byte string representing the signature value is placed in the
CounterSignature0 attribute.  This attribute is then encoded as an
unprotected header.  The attribute is defined below.
The process of creating and validating abbreviated countersignatures
is defined in Sig_structure.
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.
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 !!! .
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 !!! .
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).
The same KDF can be set up to deal with the first two types of
secrets in a different way.  The KDF defined in section 5.1 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).
The restriction applies to the encoding of the COSE_KDF_Context,
the Sig_structure, the Enc_structure, and the MAC_structure.
The rules for "Canonical CBOR" (Section 3.9 of RFC 7049) MUST be
used in these locations.  The main rule that needs to be enforced
is that all lengths in these structures MUST be encoded such that
they are using definite lengths, and the minimum length encoding
is used.
The restriction applies to the encoding of the Sig_structure, the
Enc_structure, and the MAC_structure.
IANA is requested to register a new tag for the CounterSignature
type.
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.