Telechat Review of draft-ietf-cose-tsa-tst-header-parameter-04
review-ietf-cose-tsa-tst-header-parameter-04-secdir-telechat-santesson-2025-03-13-00

I have some issues with this document of various severity.

Use cases:
Timestamping of signed documents is normally only relevant for documents that
are processed and trusted over a long time. It is generally not useful for
interactive protocol exchanges, where the signed data includes necessary
elements for asserting that the data is fresh and not a replay.

The nature of the COSE signature is naturally optimaized for use in protocol
exchanges rather than those use cases that needs time-stamp protection.

It would be useful if the Introduction could highlight in what cases COSE is a
natural choice for the types of documents that actually benefit from
timestamping.

Purpose of time stamping:
When timestamps are added as part of the signed object, it has the purpose of
asserting the time when the signature is created. This is essential to meet the
security goal to ensure that the signature was not created with compromised
credentials.

The mode "Timestamp then COSE" (TTC) violates this propose by timestamping just
the payload in a pre-signature process.

I argue that this mode has nothing to do with COSE. This is purely timestamping
of some data before being signed and I struggle to see that it is appropriate
to put such time stamp in a COSE header, as it has nothing to do with the COSE
signature.

It is also of questionable value to add this as a protected header. The TST is
signed by itself and cryptographically bound to the signed payload. I struggle
to see what the benefits are to have it protected by the COSE signature.

Security threat with pre signature timestamping (TTC).
I'm worried that the timestamp created before signing can be misunderstood by
implementers to mark a time when the signature was created. This worry is
increased by the fact that this is the way time stamps provided in signatures
normally work. If this would be the case, it would be possible to fool such
verifier by stealing a signed document with a timestamped payload before key
compromise and resigning it with a compromised key.

At a minimum, this should be highlighted in the Security Considerations, which
is silent on the topic.

Requested change
I would recommend to remove the TTC mode timestamp altogether. If a time stamp
is required of the payload data only, this should not be a COSE header as it
has nothing to do with COSE. This also removes potential security issues cased
by implementers not understanding fully that this timestamp has a completely
different security context than CTT.

It seems to me that the CTT mode does everything that TTC does, just better.