Draft: draft-ietf-cose-rfc8152bis-struct

Commentary: Edits responding to the different WGLC messages .
The procedures used to compute build the inputs to the
cryptographic functions required for each of the structures.
The procedures used to build the inputs to the cryptographic
functions required for each of the structures.
One feature that is present in CMS RFC5652 that is not present in
this standard is a digest structure.  This omission is deliberate.
It is better for the structure to be defined in each document as
different protocols will want to include a different set of fields as
part of the structure.  While an algorithm identifier and the digesst
value are going to be common to all applications, the two values may
not always be adjacent as the algorithm could be defined once with
multiple values.  Applications may additionally want to defined
additional data fields as part of the stucture.  A common structure
is going to include a URI or other pointer to where the data that is
being hashed is kept, allowing this to be application specific.
One feature that is present in CMS RFC5652 that is not present in
this standard is a digest structure.  This omission is deliberate.
It is better for the structure to be defined in each document as
different protocols will want to include a different set of fields as
part of the structure.  While an algorithm identifier and the digesst
value are going to be common to all applications, the two values may
not always be adjacent as the algorithm could be defined once with
multiple values.  Applications may additionally want to define
additional data fields as part of the stucture.  A common structure
is going to include a URI or other pointer to where the data that is
being hashed is kept, allowing this to be application specific.
Rearrange the text around counter signatures and define a CBOR Tag
for a standalong countersignature.
Rearrange the text around counter signatures and define a CBOR Tag
for a standalone countersignature.
There was not a standard CBOR grammar available when COSE was
originally written.  For that reason the CBOR structures defined here
are described in prose.  Since that time CBOR Data Definition
Language (CDDL) I-D.ietf-cbor-cddl has been published as an RFC.  The
CBOR grammar presented in this document is compatible with CDDL.
There was not a standard CBOR grammar available when COSE was
originally written.  For that reason the CBOR structures defined here
are described in prose.  Since that time CBOR Data Definition
Language (CDDL) RFC8610 has been published as an RFC.  The CBOR
grammar presented in this document is compatible with CDDL.
type1 .cbor type2 -- indicates that the contents of type1, usually
bstr, contains a value of type2.
Context is used throughout the document to represent information that
is not part of the COSE message.  Information which is part of the
context can come from several different sources including: Protocol
interactions, associated key structures and program configuration.
The context to use can be implicit, identified using the 'kid
context' header field defined in RFC8613, or identified by a protocol
specific identifier.  Context should generally be included in the
cryptographic configuration, for more details see Extern_AAD.
This parameter holds a part of the IV value.  When using the
COSE_Encrypt0 structure, a portion of the IV can be part of the
context associated with the key.  This field is used to carry a
value that causes the IV to be changed for each message.  The IV
can be placed in the unprotected header as modifying the IV will
cause the decryption to yield plaintext that is readily detectable
as garbled.  The 'Initialization Vector' and 'Partial
Initialization Vector' parameters MUST NOT both be present in the
same security layer.
This parameter holds a part of the IV value.  When using the
COSE_Encrypt0 structure, a portion of the IV can be part of the
context associated with the key (Context IV) while a portion can
be changed with each message (Parital IV).  This field is used to
carry a value that causes the IV to be changed for each message.
The Parital IV can be placed in the unprotected header as
modifying the value will cause the decryption to yield plaintext
that is readily detectable as garbled.  The 'Initialization
Vector' and 'Partial Initialization Vector' parameters MUST NOT
both be present in the same security layer.
Place the resulting signature value in the 'signature' field of
the array.
Place the resulting signature value in the correct location.  This
is the 'signature' field of the COSE_Signature, COSE_Sign1 or
COSE_Countersignature structures.  This is the value of the
Countersignature0 attribute.
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.
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
existence 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
existence of the encrypted data is attested to.  It should be noted
that there is a big difference between attesting to the encrypted
data as opposed 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.
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.
Abbreviated countersignatures were designed primarily to deal with
the problem of having group encrypted messaging, but still needing to
know who originated the message.  The objective 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 parameters for computing or verifying the
abbreviated countersignature are inferred from the same context used
to describe the encryption, signature, or MAC processing.
The CEK is encrypted with the recipient's public key.  No key
transport algorithms are defined in this document.
The CEK is encrypted in a KEK that is derived from a password.  No
password algorithms are defined in this document.
The CEK is encrypted with the recipient's public key.
The CEK is encrypted in a KEK that is derived from a password.  As
of when this document was published, no password algorithms have
been defined.
In this section, a taxonomy of the different algorithm types that can
be used in COSE is laid out.  This taxonomy should not be considered
to be exhaustive as there are new algorithm structures that could be
found or are not known to the author.
MAC algorithms can be based on either a block cipher algorithm (i.e.,
AES-MAC) or a hash algorithm (i.e., a Hash-based Message
Authentication Code (HMAC)).  This document defines a MAC algorithm
using each of these constructions.
MAC algorithms can be based on either a block cipher algorithm (i.e.,
AES-MAC) or a hash algorithm (i.e., a Hash-based Message
Authentication Code (HMAC)).  I-D.ietf-cose-rfc8152bis-algs defines a
MAC algorithm using each of these constructions.
Encoding MUST be done using definite lengths and the length of the
MUST be the minimum possible length.  This means that the integer
1 is encoded as "0x01" and not "0x1801".
Encoding MUST be done using definite lengths and values MUST be
the minimum possible length.  This means that the integer 1 is
encoded as "0x01" and not "0x1801".
An example of a profile can be found in I-D.ietf-core-object-security
where a profiles was developed for carrying content in combination
with CoAP headers.
An example of a profile can be found in RFC8613 where one was
developed for carrying content in combination with CoAP headers.
Implementations need to protect the private key material for any
individuals.  There are some cases in this document that need to be
highlighted on this issue.
Implementations need to protect the private key material for any
individuals.  There are some cases that need to be highlighted on
this issue.
Several of the algorithms in this document have limits on the
number of times that a key can be used without leaking information
about the key.
Several of the algorithms in I-D.ietf-cose-rfc8152bis-algs have
limits on the number of times that a key can be used without
leaking information about the key.
There are a large number of algorithms presented in this document
that use nonce values.  For all of the nonces defined in this
document, there is some type of restriction on the nonce being a
unique value either for a key or for some other conditions.  In all
of these cases, there is no known requirement on the nonce being both
unique and unpredictable; under these circumstances, it's reasonable
to use a counter for creation of the nonce.  In cases where one wants
the pattern of the nonce to be unpredictable as well as unique, one
can use a key created for that purpose and encrypt the counter to
produce the nonce value.
There are a large number of algorithms presented in I-D.ietf-cose-
rfc8152bis-algs that use nonce values.  Nonces generally have some
type of restriction on their values.  Generally a nonce needs to be a
unique value either for a key or for some other conditions.  In all
of these cases, there is no known requirement on the nonce being both
unique and unpredictable; under these circumstances, it's reasonable
to use a counter for creation of the nonce.  In cases where one wants
the pattern of the nonce to be unpredictable as well as unique, one
can use a key created for that purpose and encrypt the counter to
produce the nonce value.