I honestly hate to give bad feedback, but as I'm assigned the SecDir reviewer of this document. I do feel obligated to share my concerns which to the most part repeat the concerns of my last review.
My motivation for providing this feedback is genuine concern that the current document may unintentionally lead to vulnerable implementations.

Logic reversal causing confusion:
The proposed TTC (Timestamp Then COSE) option introduces reversed logic compared to established cryptographic timestamping practices (RFC 3161 timestamps from a TSA), as seen in CMS, XML signatures, JOSE, and ETSI standards (XAdES, CAdES, PAdES, JAdES). Traditionally, timestamps from a TSA are applied over the signature data to clearly establish proof that the signature existed at or before the stated time. In contrast, placing a timestamp that only covers the payload and not any signature data is a clear deviation from practice. The fact that this timestamp still appears in a signature header, despite having nothing to do with the signature, may trigger false assumptions that it is semantically bound to the signature itself. Although the semantics are clearly stated, this deviation from traditional timestamping practice may cause significant confusion and lead implementers to make incorrect assumptions based on their prior experience with signature timestamps.


Threat scenario:
This is the scenario that worries me:Consider the following scenario with two different developers contributing to different parts of the validation logic:

Developer A parses and validates COSE signatures but intentionally does not handle certificate path validation. This is a quite common approach as most validation scenarios involves pre-trusted keys rather than certificate path validation. This developer outputs parsed data objects, easy to be consumed by a calling application layer that handles key or certificate validation. This includes data about the different timestamps, correctly validated and tagged by their header identifier.

Developer B, responsible for certificate validation based on RFC 5280 and RFC 3161 timestamps, consumes the correctly pared signature data provided by Developer A. Developer B, unfamiliar with the novel TTC timestamp semantics, erroneously assumes that the payload-only timestamp represents a signature creation time. Consequently, Developer B incorrectly validates a signature created after a signing key was compromised and its certificate revoked, relying on a pre-compromise payload timestamp, leading to successful validation.

This vulnerability is serious but is of a kind that likely will not be caught by unit tests or integration tests unless the tester is very creative. When everyone does the right thing, everything works.


I do have to say that I can see reasonable benefits with TTC. But I would personally like to prioritize security over the benefits in this case. My primary recommendation would be to align with other signature standards and not include TTC at all and pursue other alternatives for this need (such as solutions inside the payload). But as I fear that this will not be the selected path. I would then at least give the TTC header a name that clearly makes an implementer think twice. Such as "non-signature-timestamp" or "payload-only-timestamp" or similar. "3161-ttc" is not informative enough and the second developer may not react appropriately to the important semantical difference from "3161-ctt" as this developer is not a COSE expert and therefore commonly only reads the details of this RFC if he has to.


Security Considerations update proposal:

The Security Considerations section has been improved, but I think the current text is inadequate.
If the TTC functionality remains in the specification, the Security Considerations section should explicitly highlight this risk. I propose adding something like:

"Implementers MUST clearly differentiate between RFC 3161 TSA timestamps proving the existence of payload data at an earlier point in time and timestamps explicitly providing evidence of the existence of the cryptographic signature. Failure to clearly distinguish between these timestamp semantics could result in vulnerabilities, such as incorrectly accepting signatures created after key revocation based on older payload-only timestamps. Validators MUST NOT interpret protected-header payload timestamps as proof of signature creation time and SHOULD rely exclusively on RFC 3161 TSA timestamps explicitly covering signature data for determining signature validity timing."


Thank you for considering this feedback aimed to enhance clarity and security.