Code change:
affirming multiple Issuers agree. At least one identifier representing one credential MUST be included <del> in the protected header of the COSE Envelope, as one of "x5t" or "kid".  Additionally, "x5chain" that corresponds to either "x5t" or "kid" identifying the leaf certificate in the included certification path MAY be included in the unprotected header of the COSE Envelope. </del> <ins> in the protected header of the COSE Envelope, as one of "x5t", "x5chain" or "kid".  Additionally, "x5chain" that corresponds to either "x5t" or "kid" identifying the leaf certificate in the included certification path MAY be included in the unprotected header of the COSE Envelope. </ins> <del> When using x.509 certificates, support for "x5t" is REQUIRED to implement. </del> <ins> When using x.509 certificates, support for either "x5t" or "x5chain" in the protected header is REQUIRED to implement. </ins> Support for "kid" in the protected header and "x5chain" in the unprotected header is OPTIONAL to implement. <del> When "x5t" is present, "iss" MUST be a string that meets URI requirements defined in RFC8392.  The "iss" value's length MUST be between 1 and 8192 characters in length. </del> <ins> When "x5t" or "x5chain" is present in the protected header, "iss" MUST be a string that meets URI requirements defined in RFC8392.  The "iss" value's length MUST be between 1 and 8192 characters in length. </ins> <del> The "kid" header parameter MUST be present when "x5t" is not present. Key discovery protocols are out-of-scope of this document. </del> <ins> The "kid" header parameter MUST be present when neither "x5t" nor "x5chain" is present in the protected header.  Key discovery protocols are out-of-scope of this document. </ins> The protected header of a Signed Statement and a Receipt MUST include the "CWT Claims" header parameter as specified in CWT_CLAIMS_COSE.

Related discussion:
text: by allowing the use of a single, protected header parameter instead of a protected and unprotected pair, for reasons described in the issue. This allows implementations to avoid the risk highlighted at the end of , at the expense of a slightly larger protected header. This is not a purely theoretical concern, the most widely used signing service inside Microsoft has implemented this choice, and the separate from Microsoft has too.
The current text mandates the presence of in the protected header when using x509: URL, and allows an unprotected x5chain: URL I propose that the specification allows in the protected header, ideally as a substitute for , but in addition otherwise. The motivation for this change is to add a degree of integrity protection over , and blame for malicious payload otherwise. The current set up does not authenticate or integrity protect the contents of x5chain, only the leaf, which opens up some opportunities for attacks targeting x509 parsers. I can see why this minimal binding can be desirable in some cases (caching large cert chains), but servers that wish to be stricter to reduce their attack surface should be able to.
Thanks for the fix. Seems quite valuable to the overall operation! LGTM!LGTM thanks. For completeness of the record, I was previously against mandatory x5chain and mandatory deep, possibly online checks of the links in the chain. This PR looks eminently sensible for people who want to rely on x5chainDiscussion at the editors meeting to approve. LGTM