I have reviewed draft-ietf-cose-type-header-parameters as part of
the security directorate's ongoing effort to review all IETF
documents being processed by the IESG. These comments were written
primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any
other last call comments

I do not see any serious problems with this draft.  However, there are a number of minor things that need changing that go beyond nits, so I am rating this as having issues.

1. Comments in the security considerations are all relevant and necessary.  My only suggestion is to mention that it also inherits the security considerations of 8901, 8078, and 7477.

2.All acronyms should be defined, e.g. in a glossary.

3. The terms “parent should be defined.

4.  The term “trust mechanism” should be defined.  I assume that goes beyond just authenticating a principal but determining that it is authorized to do its job, but this should be stated clearly.

5.  In section 4.2.2 it says

The minimum DNSKEY Waiting Time is the maximum of all DNSKEYS TTL
values from all signers plus the time it takes to publish the zone
on all secondaries.

How is the latter computed?  Or is the way the it is computed left up to the implementor? 

6.  This is the one I had the most trouble with. 4.9.  appears to be saying that a setup in which different signers use different key  algorithms either MUST NOT be allowed, or SHOULD be allowed, depending on which RFC you read.  But then it says “So a Multi-Signer setup where different signers use different key
algorithms should still validate.”   I’m not sure why this conclusion is made, unless it’s because SHOULD always outranks MUST NOT.  But I don’t see anything in RFC 2119 about that.  That should be clarified.  Note that this does not mean I see anything wrong with the reasoning with the rest of 4.9; it seems reasonable.  But it seems to be discussing a scenario that is already ruled out by the RFCs, and there no instructions for handling this case in the current draft.  This needs be clarified.

Finally, some nits:

1. 4.1 number 4: signer or controller, number 4.  I think “signer controller” should be “signer or controller”

Each Signer to be added, including the initial Signer, must meet the
following prerequisites before joining the Multi-Signer Group
   1. A working setup of the zone, including DNSSEC signing.

If the zone is the zone the Signer is entering, then it can’t be considered an attribute of the signer.   This is confusing and the wording should be changed.

2. Section 4.9 doesn’t have any content.

3. Security considerations, second paragraph:  “steps to allows” should be “steps to allow”