Change:
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.

Discussion:
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 <del> a bstr object.  This wrapping allows for the encoding of the </del> <ins> 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 </ins> 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

origination.  (One cannot, for example, be used to prove the identity of the sender to a third party.) <ins> MACs are designed in the same basic structure as signature with appendix algorithms.  The message content is processed and an authentication code is produced, the authentication code is frequently called a tag.  The basic structure becomes: </ins> MAC algorithms can be based on either a block cipher algorithm (i.e. AES-MAC) or a hash algorithm (i.e.  HMAC).  This document defines a MAC algorithm for each of these two constructions.

10. <ins> 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. We restrict the set of legal content encryption algorithms to those which support authentication both of the content and additional data. The encryption process will generate some type of authentication value, but that value may be either explicit or implicit in terms of the algorithm definition.  For simplicity sake, the authentication code will normally be defined as being appended to the cipher text stream.  The basic structure becomes: 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. </ins> 10.1. The GCM mode is is a generic authenticated encryption block cipher

11. <ins> Key Derivation Functions (KDFs) are used to take some secret value and generate a different one.  The original secret values come in three basic flavors: 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. </ins> 11.1. The HKDF key derivation algorithm is defined in RFC5869.