Draft: draft-ietf-cose-rfc8152bis-algs

Commentary: Deal with the second round of WGLC comments Do some v3 vocabulary cleanup
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.
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 an initial set of algorithms for use with those
structures.  Additional algorithms beyond what are in this document
are defined elsewhere.
The HMAC algorithm is parameterized by an inner and outer padding, a
hash function (h), and an authentication tag value length.  For this
specification, the inner and outer padding are fixed to the values
set in RFC2104.  The length of the authentication tag corresponds to
the difficulty of producing a forgery.  For use in constrained
environments, we define one HMAC algorithms that is truncated.  There
are currently no known issues with truncation; however, the security
strength of the message tag is correspondingly reduced in strength.
When truncating, the leftmost tag length bits are kept and
transmitted.
The HMAC algorithm is parameterized by an inner and outer padding, a
hash function (h), and an authentication tag value length.  For this
specification, the inner and outer padding are fixed to the values
set in RFC2104.  The length of the authentication tag corresponds to
the difficulty of producing a forgery.  For use in constrained
environments, we define one HMAC algorithm that is truncated.  There
are currently no known issues with truncation; however, the security
strength of the message tag is correspondingly reduced in strength.
When truncating, the leftmost tag length bits are kept and
transmitted.
The key and nounce values MUST be a unique pair for every invocation
of the algorithm.  Nonce counters are considered to be an acceptable
way of ensuring that they are unique.
The key and nonce values MUST be a unique pair for every invocation
of the algorithm.  Nonce counters are considered to be an acceptable
way of ensuring that they are unique.
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.
COSE does not have an Ephemeral-Ephemeral version defined.  The
reason for this is that COSE is not 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.
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.
COSE_Mac0, one effectively upgrades the MAC operation to a signature
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.
COSE supports two different MAC structures.  COSE_MAC0 is used when a
recipient structure is not needed because the key to be used is
implicitly known.  COSE_MAC is used for all other cases.  These
include a requirement for multiple recipients, the key being unknown,
and a recipient algorithm of other than direct.
COSE supports two different MAC structures.  COSE_MAC0 is used when a
recipient structure is not needed because the key to be used is
implicitly known.  COSE_MAC is used for all other cases.  These
include a requirement for multiple recipients, the key being unknown,
or a recipient algorithm of other than direct.
Although it has been mentioned before, the use of a single key for
multiple algorithms has been demonstrated in some cases to leak
information about a key, provide the opportunity for attackers to
forge integrity tags, or gain information about encrypted content.
Binding a key to a single algorithm prevents these problems.  Key
creators and key consumers are strongly encouraged not only to create
new keys for each different algorithm, but to include that selection
of algorithm in any distribution of key material and strictly enforce
the matching of algorithms in the key structure to algorithms in the
message structure.  In addition to checking that algorithms are
correct, the key form needs to be checked as well.  Do not use an
'EC2' key where an 'OKP' key is expected.
Although it has been mentioned before, the use of a single key for
multiple algorithms has been demonstrated in some cases to leak
information about that key, provide the opportunity for attackers to
forge integrity tags, or gain information about encrypted content.
Binding a key to a single algorithm prevents these problems.  Key
creators and key consumers are strongly encouraged not only to create
new keys for each different algorithm, but to include that selection
of algorithm in any distribution of key material and strictly enforce
the matching of algorithms in the key structure to algorithms in the
message structure.  In addition to checking that algorithms are
correct, the key form needs to be checked as well.  Do not use an
'EC2' key where an 'OKP' key is expected.