COSE Header parameter for RFC 3161 Time-Stamp Tokens
draft-ietf-cose-tsa-tst-header-parameter-08

[Ballot comment]
The changes to version 7 of this specification were good enough that I have cleared my discuss.

Possibly the comment below wasn't clear enough?  I can go back and see if I can state the issue more clearly?  Let me know, and I will try again.
------------------------------------------------------
Original comment:
Section 1.1, para 4:  A small clarification, if the TST is acquired before the statement is signed, then the relying party knows that the statement was signed by the issuer 'not before' the times specified by the TSA.  This is an early bound (vice a no later bound in the first case).

[Ballot discuss]
Thanks to Stefan Santesson for the repeated secdir reviews.  These reviews have driven change to create a better specification.  The authors are lucky to have drawn a reviewer that is well versed in the subject of timestamps.  I'm not sure it is possible to completely eliminate the issue of a choosing the wrong method, but I hope recent changes have made it harder for the developer to make that mistake.  I will make a few comments which I hope will make it a tiny bit harder.

Names of modes:  Stefan points out that the two mode names are similar, perhaps too similar.  Instead of choosing the mode names by the order of operation, maybe mode names that describe the operation.  Perhaps 'certificate timestamps' and 'unsigned statement timestamps', recognizing that these don't create nice acronyms, and that it is a pretty pervasive change to the draft.

Section 1.1:  Add a sentence to the first para that this specification outlines the original mode and a new mode, where the security characteristics are different so care needs to be taken to choose the appropriate mode.

Section 1.1, para 2&3:  Please consider stating that this use case is the primary, or original use case that most implementations will use. Something like 'The original use case....'  and then 'This primary usage scenario motivates....'

Section 1.1, para 4&5:  Please consider stating that this is a new use case for very specific purposes.  Something like 'The new use case...' and then 'This new usage scenario....'

[Ballot comment]

Section 1.1, para 4:  A small clarification, if the TST is acquired before the statement is signed, then the relying party knows that the statement was signed by the issuer 'not before' the times specified by the TSA.  This is an early bound (vice a no later bound in the first case).

Note this document was moved from IESG ballot state to be returned to the WG because it was out of charter. The charter was updated and the document was moved back to go through another IESG telechat without an new IETF LC. Looking back, I should have left the document as-is instead of moving it back to the WG. This was a process failure on my end.

Document History

Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

The specification does one simple thing that has working group support.  Most of the on-list discussion happened during WGLC, with about 10 people participating, some providing substantive feedback that was addressed after WGLC.  The document has working group consensus.

Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

The was not controversy.  The feedback received was largely about the exposition.  This is bringing an existing mechanism to COSE.

Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

I am not aware of any threatened appeals or extreme discomfort.

For protocol documents, are there existing implementations of the contents of
the document? Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere,
either in the document itself (as RFC 7942 recommends) or elsewhere
(where)?

C2PA 2.1 uses this specification, and is implemented by Microsoft, Google, and Trupic.  Measur.io has an implementation.

Additional Reviews

Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

Not that I'm aware of.

Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No such criteria apply.

If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in RFC 8342?

The document contains no YANG module.

Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

Document Shepherd Checks

Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

This document solves a narrow but useful problem and solves it well.  It is ready to hand off to our AD.

Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

It doesn't appear that most of the common Security Area issues at https://wiki.ietf.org/group/sec/typicalSECareaissues apply, other than Thread Models, which are discussed in the Security Considerations section.

What type of RFC publication is being requested on the IETF stream (Best
Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard status is being requested, and is accurately reflected in the datatracker.  This status seems appropriate for the specification.

Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.

All three authors have responded that they are not aware of any IPR considerations that apply to the specification.

Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes, they are willing.

Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

I believe that the reference [IANA.cose_header-parameters] should be informative.  Also, stylistially, it would appear to be better to use either dash or underscore in the reference, but not both in a mixed fashion.

Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.

I believe that the reference [IANA.cose_header-parameters] should be informative.

List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?

There are no such references.

Are there any normative downward references (see RFC 3967 and BCP
97) that are not already listed in the DOWNREF registry? If so,
list them.

There are no such references.

Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

There are no such references.

Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

Publication of this document will not change the status of any existing RFCs.

Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).

The IANA Considerations section appears to be consistent with the rest of the specification.

List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

The specification creates no new IANA registries.

[Ballot discuss]
Two items: 

I agree with Stefan Santesson's review:  https://mailarchive.ietf.org/arch/msg/secdir/yiKmZx9ivRJZfUdj5g8W1HPB5xM/  (many thanks for that secdir review)

Section 5:  These types of systems rely on accurate time, and prompt reporting of compromised keys.  STD96 discusses the necessity of keeping private keys private, but does not discuss the prompt reporting when those keys are disclosed.  I think two short warnings (one on the necessity for the accuracy of time, and one on the prompt reporting of compromised keys) would be useful for someone using/implementing this document.  (I'm happy to help with the words for these two warnings)

[Ballot comment]
I support Roman's DISCUSS regarding charter status. The remaining comments can hopefully be used to improve the document if and when it is submitted by a WG whose charter permits it.

The 2119 MUST in the first sentence of 3.x is unnecessary -- if a different field were used, it wouldn't be what's defined in this specification. You can simply say that these headers are used for the corresponding purposes. However, a more useful 2119 keyword might be in mandating that the header be protected/unprotected as appropriate; if this header appears in the wrong section then the security properties won't apply.

The examples in 3.2.x don't specify behavior; they might be better placed in Appendix A, which already contains examples. (Do the two sets of examples illustrate different things?)

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-cose-tsa-tst-header-parameter-05
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points.

Special thanks to Michael Jones for the shepherd's write-up including the WG consensus but the justification of the intended status is rather light.

Other thanks to Alexey Melnikov, the IoT directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-cose-tsa-tst-header-parameter-05-iotdir-telechat-melnikov-2025-04-30/ (and I have read Thomas' reply)

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Fit the COSE charter ?

I support Roman's DISCUSS on this I-D not fitting the COSE charter.

### Section 1.1

Please expand "TSA" at first use.

Add reference(s) for TSA (RFC 3161 ?) & "Transparency Service".

### Section 2

Isn't 'boxes' unclear in `by allowing multiple private-key boxes` ?

### Section 2.1

Thanks for using SVG graphics, much cleaner.

Should clock also be considered as input in the TSA box in figure 1 ? The graphics seems to indicate that the private key is feeded in the clock...

[Ballot discuss]
# Orie Steele, ART AD, comments for draft-ietf-cose-tsa-tst-header-parameter-05
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-cose-tsa-tst-header-parameter-05.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Discuss

Thanks to Shuping Peng for the ARTART review.

### Transparency Service

The term is capitalized, but no definition is provided.
Given the origin of the draft in scitt, its implied that this is the same TS that the SCITT Architecture describes.
However, SCITT architecture does not support registering anything in the unprotected header (can't support CTT).

https://datatracker.ietf.org/doc/html/draft-ietf-scitt-architecture-11#section-6.2-6

### CTT

```
122   entry cannot be changed.  In certain cases, such as when a short-
123   lived certificate is used for the signature, the registration policy
124   of a Transparency Service may add a trustworthy timestamp to the
125   signed document.  This is done to lock the signature to a specific
126   point in time.  To achieve this, the Transparency Service acquires a
127   TST from a TSA, bundles it alongside the signed document, and then
128   registers it.  A relying party that wants to ascertain the
129   authenticity of the document after the signing key has expired (or
130   has been compromised), can do so by making sure that no revocation
131   information has been made public before the time asserted in the TST.
```

MUST the TSA be a separate entity from the Transparency Service?

Is it possible for the document signer to supply the TST instead of the Transparency Service?

What happens if there is already a TST present, when the Transparency Service receives the cose object?

[Ballot discuss]
For the responsible AD and WG chairs -- this document is not in scope for the current WG charter.  My understanding of its substance is that it defines two, new COSE attributes.  The approved -03 charter explicitly says:

“The WG will produce documents for new attributes only if they are in the
list of deliverables below. A re-charter will be required to expand that list.
The WG is expected as part of normal processing to review and comment on
attributes that are not in charter but are of general public interest.”

There is no subsequent reference to work about specifying timestamp related attributes in the work items section of the charter (or any other place).

[Ballot comment]
Hi Henk, Thomas, and Maik,

Thank you for the effort put into this specification.

Thanks to Yingzhen Qu for the OPSDIR review.

The spec is straightforward. There are some guidelines when manipulating timestamps (e.g., rfc8877), but I don’t think those apply here.

I trust the authors have validated all the examples.

Please find below some few comments:

# Hash details: can we have an authoritative reference to zoom more about how the hash is computed/validated?

CURRENT:
  The MessageImprint sent to the TSA (Section 2.4 of [RFC3161]) MUST be
  the hash of the payload of the COSE signed object. 

# Add a normative reference to RFC 8792 as that is required for unfolding

# The use of folding is not consistent

For example, this is not used in 3.2.1, while it is used in other examples.

# Check/fix some uses of folding in the last example, in particular:

CURRENT:
      / signature / h'8eb33e4ca31d1c465ab05aac34cc6b23d58fef5c083106c4
  d25a91aef0b0117e2af9a291aa32e14ab834dc56ed2a223444547e01f11d3b0916e5
  a4c345cacb36'

Thank you.

Cheers,
Med

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-cose-tsa-tst-header-parameter-03. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which we must complete.

In the COSE Header Parameters registry in the CBOR Object Signing and Encryption (COSE) registry group located at:

https://www.iana.org/assignments/cose/

two new parameters will be registered as follows:

Name: 3161-tcc
Label: [ TBD-at-Registration ]
Value Type: bstr
Value Registry:
Description: RFC 3161 timestamp token
Reference: [ RFC-to-be; Section 3.1 ]

Name: 3161-ctt
Label: [ TBD-at-Registration ]
Value Type: bstr
Value Registry:
Description: RFC 3161 timestamp token
Reference: [ RFC-to-be; Section 3.2 ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The action requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the action that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-01-13):

From: The IESG
To: IETF-Announce
CC: cose-chairs@ietf.org, cose@ietf.org, draft-ietf-cose-tsa-tst-header-parameter@ietf.org, michael_b_jones@hotmail.com, paul.wouters@aiven.io
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (COSE Header parameter for RFC 3161 Time-Stamp Tokens) to Proposed Standard


The IESG has received a request from the CBOR Object Signing and Encryption
WG (cose) to consider the following document: - 'COSE Header parameter for
RFC 3161 Time-Stamp Tokens'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-01-13. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines a CBOR Signing And Encrypted (COSE) header
  parameter for incorporating RFC 3161-based timestamping into COSE
  message structures (COSE_Sign and COSE_Sign1).  This enables the use
  of established RFC 3161 timestamping infrastructure to prove the
  creation time of a message.

Discussion Venues

  This note is to be removed before publishing as an RFC.

  Source for this draft and an issue tracker can be found at
  https://github.com/ietf-scitt/draft-birkholz-cose-tsa-tst-header-
  parameter.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-cose-tsa-tst-header-parameter/



No IPR declarations have been submitted directly on this I-D.

Document History

Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

The specification does one simple thing that has working group support.  Most of the on-list discussion happened during WGLC, with about 10 people participating, some providing substantive feedback that was addressed after WGLC.  The document has working group consensus.

Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

The was not controversy.  The feedback received was largely about the exposition.  This is bringing an existing mechanism to COSE.

Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

I am not aware of any threatened appeals or extreme discomfort.

For protocol documents, are there existing implementations of the contents of
the document? Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere,
either in the document itself (as RFC 7942 recommends) or elsewhere
(where)?

C2PA 2.1 uses this specification, and is implemented by Microsoft, Google, and Trupic.  Measur.io has an implementation.

Additional Reviews

Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

Not that I'm aware of.

Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No such criteria apply.

If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in RFC 8342?

The document contains no YANG module.

Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

Document Shepherd Checks

Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

This document solves a narrow but useful problem and solves it well.  It is ready to hand off to our AD.

Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

It doesn't appear that most of the common Security Area issues at https://wiki.ietf.org/group/sec/typicalSECareaissues apply, other than Thread Models, which are discussed in the Security Considerations section.

What type of RFC publication is being requested on the IETF stream (Best
Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard status is being requested, and is accurately reflected in the datatracker.  This status seems appropriate for the specification.

Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.

All three authors have responded that they are not aware of any IPR considerations that apply to the specification.

Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes, they are willing.

Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

I believe that the reference [IANA.cose_header-parameters] should be informative.  Also, stylistially, it would appear to be better to use either dash or underscore in the reference, but not both in a mixed fashion.

Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.

I believe that the reference [IANA.cose_header-parameters] should be informative.

List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?

There are no such references.

Are there any normative downward references (see RFC 3967 and BCP
97) that are not already listed in the DOWNREF registry? If so,
list them.

There are no such references.

Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

There are no such references.

Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

Publication of this document will not change the status of any existing RFCs.

Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).

The IANA Considerations section appears to be consistent with the rest of the specification.

List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

The specification creates no new IANA registries.

Document History

Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

The specification does one simple thing that has working group support.  Most of the on-list discussion happened during WGLC, with about 10 people participating, some providing substantive feedback that was addressed after WGLC.  The document has working group consensus.

Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

The was not controversy.  The feedback received was largely about the exposition.  This is bringing an existing mechanism to COSE.

Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

I am not aware of any threatened appeals or extreme discomfort.

For protocol documents, are there existing implementations of the contents of
the document? Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere,
either in the document itself (as RFC 7942 recommends) or elsewhere
(where)?

C2PA 2.1 uses this specification, and is implemented by Microsoft, Google, and Trupic.  Measur.io has an implementation.

Additional Reviews

Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

Not that I'm aware of.

Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No such criteria apply.

If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in RFC 8342?

The document contains no YANG module.

Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

Document Shepherd Checks

Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

This document solves a narrow but useful problem and solves it well.  It is ready to hand off to our AD.

Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

It doesn't appear that most of the common Security Area issues at https://wiki.ietf.org/group/sec/typicalSECareaissues apply, other than Thread Models, which are discussed in the Security Considerations section.

What type of RFC publication is being requested on the IETF stream (Best
Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard status is being requested, and is accurately reflected in the datatracker.  This status seems appropriate for the specification.

Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.

All three authors have responded that they are not aware of any IPR considerations that apply to the specification.

Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes, they are willing.

Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

I believe that the reference [IANA.cose_header-parameters] should be informative.  Also, stylistially, it would appear to be better to use either dash or underscore in the reference, but not both in a mixed fashion.

Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.

I believe that the reference [IANA.cose_header-parameters] should be informative.

List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?

There are no such references.

Are there any normative downward references (see RFC 3967 and BCP
97) that are not already listed in the DOWNREF registry? If so,
list them.

There are no such references.

Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

There are no such references.

Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

Publication of this document will not change the status of any existing RFCs.

Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).

The IANA Considerations section appears to be consistent with the rest of the specification.

List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

The specification creates no new IANA registries.