Draft: draft-ietf-cose-msg

Commentary: Merge in the WebCrypto view of the world for key ops 
 I believe that this matches now . Thanks . 
  has suggested that we could eliminate the need for the COSE_MSG structure if we were to get tags assigned from CBOR for these structures . Should this be done ? 
 a ) CBOR Tag - either general or specific to each type b ) Required Identifier c ) Use the same techniques as  There was no support for option C. There was support for Option B There was some support for Option A , but only if it was optional .   suggested that we should use the header parameter ' typ ' , I responded to this message saying that it was not clear that this was a correct use of the field based on the description in the  document . At this point I will keep the field as mandatory and outside of the headers field . I am planning on doing the IANA request for a CBOR Tag and to keep the tag as being optional in the grammar and text . 
 Closed in  request
If the 'alg' field present, it MUST match the ECDSA signature
algorithm being used.
If the 'key_ops' field is present, it MUST include 'sign' when
creating an ECDSA signature.
If the 'key_ops' field is present, it MUST include 'verify' when
verifying an ECDSA signature.
If the key is obtained from a key structure, the key type MUST be
'Symmetric'.  Implementations creating and validating MAC values MUST
validate that the key type, key length, and algorithm are correct and
appropriate for the entities involved.
If the 'alg' field present, it MUST match the HMAC algorithm being
used.
If the 'key_ops' field is present, it MUST include 'sign' when
creating an HMAC authentication tag.
If the 'key_ops' field is present, it MUST include 'verify' when
verifying an HMAC authentication tag.
Implementations creating and validating MAC values MUST validate that
the key type, key length, and algorithm are correct and appropriate
for the entities involved.
Keys may be obtained either from a key structure or from a recipient
structure.  If the key obtained from a key structure, the key type
MUST be 'Symmetric'.  Implementations creating and validating MAC
values MUST validate that the key type, key length and algorithm are
correct and appropriate for the entities involved.
Keys may be obtained either from a key structure or from a recipient
structure.  Implementations creating and validating MAC values MUST
validate that the key type, key length and algorithm are correct and
appropriate for the entities involved.
If the 'alg' field present, it MUST match the AES-MAC algorithm
being used.
If the 'key_ops' field is present, it MUST include 'sign' when
creating an AES-MAC authentication tag.
If the 'key_ops' field is present, it MUST include 'verify' when
verifying an AES-MAC authentication tag.
If the 'alg' field present, it MUST match the AES-GCM algorithm
being used.
If the 'alg' field present, it MUST match the AES-CCM algorithm
being used.
If the 'alg' field present, it MUST match the ChaCha algorithm
being used.
If the 'alg' field present, it MUST match the KDF algorithm being
used.
If the 'key_ops' field is present, it MUST include 'deriveKey or
'deriveBits'.
If the 'alg' field present, it MUST match the AES Key Wrap
algorithm being used.
Ephemeral-Static DH: where the sender of the message creates a one
time DH key and uses a static key for the recipient.  The use of
the ephemeral sender key means that no additional random input is
needed as this is randomly generated for each message.