Draft: draft-ietf-cose-msg

Commentary: Add more intro text to algorithms Put in a note about the fact that a zero length map is not the preferred encoding for the protected field , but is a legal one .
contains parameters about the current layer that are to be
cryptographically protected.  This bucket MUST be empty if it is
not going to be included in a cryptographic computation.  This
bucket is encoded in the message as a binary object.  This value
is obtained by CBOR encoding the protected map and wrapping it in
a bstr object.  This wrapping allows for the encoding of the
protected map to be transported with a greater chance that it will
not be altered in transit.  (Badly behaved intermediates could
decode and re-encode, but this will result in a failure to verify
unless the re-encoded byte string is identical to the decoded byte
string.)  This finesses the problem of all parties needing to be
able to do a common connical encoding.
contains parameters about the current layer that are to be
cryptographically protected.  This bucket MUST be empty if it is
not going to be included in a cryptographic computation.  This
bucket is encoded in the message as a binary object.  This value
is obtained by CBOR encoding the protected map and wrapping it in
a bstr object.  Senders SHOULD encode an empty protected map as a
zero length binary object (it is shorter).  Recipients MUST accept
both a zero length binary value and a zero length map encoded in
the binary value.  The wrapping allows for the encoding of the
protected map to be transported with a greater chance that it will
not be altered in transit.  (Badly behaved intermediates could
decode and re-encode, but this will result in a failure to verify
unless the re-encoded byte string is identical to the decoded byte
string.)  This finesses the problem of all parties needing to be
able to do a common connical encoding.
Content Encryption Algorithms provide data confidentialty for
potentially large blocks of data using a symmetric key.  They provide
either no or very limited data origination.  (One cannot, for
example, be used to prove the identity of the sender to a third
party.)  The ability to provide data origination is linked to how the
symmetric key is obtained.
Most AEAD algorithms are logically defined as returning the message
content only if the decryption is valid.  Many but not all
implementations will follow this convention.  The message content
MUST NOT be used if the decryption does not validate.
Secrets which are uniformly random: This is the type of secret
which is created by a good random number generator.
Secrets which are not uniformly random: This is type of secret
which is created by operations like key agreement.
Secrets which are not random: This is the type of secret that
people generate for things like passwords.
General KDF functions work well with the first type of secret, can do
reasonable well with the second type of secret and generally do
poorly with the last type of secret.  None of the KDF functions in
this section are designed to deal with the type of secrets that are
used for passwords.  Functions like PBSE2 RFC2898 need to be used for
that type of secret.
Many functions are going to handle the first two type of secrets
differently.  The KDF function defined in HKDF can use different
underlying constructions if the secret is uniformly random than if
the secret is not uniformly random.  This is reflected in the set of
algorithms defined for HKDF.
When using KDF functions, one component that is generally included is
context information.  Context information is used to allow for
different keying information to be derived from the same secret.  The
use of context based keying material is considered to be a good
security practice.  This document defines a single context structure
and a single KDF function.