Change:
Multiple "aesgcm128" values are not permitted. An application server MUST include exactly one entry in each of the <del> Encryption and Encryption-Key header fields.  This allows the "keyid" </del> <ins> Encryption and Crypto-Key header fields.  This allows the "keyid" </ins> parameter to be omitted from both header fields. <del> An application server MUST NOT include a "key" parameter in the Encryption header field. </del> <ins> An application server MUST NOT include an "aesgcm128" parameter in the Encryption header field. </ins> 4. A User Agent decrypts messages are decrypted as described in I- <del> D.thomson-http-encryption.  The value of the "keyid" parameter is used to identify the correct key pair, if there is more than one possible value for the corresponding subscription. </del> <ins> D.thomson-http-encryption.  The authentication secret described in derivation is used in key derivation. Note that the value of the "keyid" parameter is used to identify the correct share, if there are multiple values for the Crypto-Key header field. </ins> A receiver is not required to support multiple records.  Such a receiver MUST check that the record size is large enough to contain

Discussion:
Adam Langley and David Benjamin identified a risk with the proposed security design for push messages. In the existing design, a user agent shares two pieces of information with an application server that form the basis of authenticating messages. endpoint - The secrecy of the endpoint URL is used to protect the user agent from receiving unauthenticated and unwanted messages. Unfortunately, this URL is necessarily known to user agent, push service and application server, so any of those three can generate spam. DH public key - The secrecy of the Diffie-Hellman public key is relied on to ensure that a valid push message can't be sent by anyone other than the application server. Only the user agent and the application server know this information. The concern here is that a DH public key is not typically treated like a secret. That means that when it is used, there is no guarantee that an implementation won't leak bits of the public key. For instance, if an implementation isn't constant time with respect to its contents, . If this secret is leaked to the push service, then the push service is able to generate push messages that will be accepted by the user agent. Those messages will appear to come from the application server. In the modern spirit of belt-and-braces design for security protocols, this change adds a new authentication secret that the application server has to prove ownership of to send a message. This secret is mixed into the key derivation process. Any entity that doesn't know this value will be unable to derive a valid content encryption key. The suggested alternative, a HMAC key, was rejected on the basis that it increased the signaling load on the path from application server -> push service -> user agent. This provides similar protection without increasing the size of push messages. This change builds on martinthomson/http-encryption by adding the authentication secret to the context that is passed as the HKDF label.
Attention NAME
Updated to be based on martinthomson/http-encryption based on URL