Telechat Review of draft-ietf-cose-tsa-tst-header-parameter-06
review-ietf-cose-tsa-tst-header-parameter-06-secdir-telechat-santesson-2025-07-31-00

This is my third review of the same document in various versions.

I have previously marked this as having serious issues. I have now downgraded
this to just “have issues” just to acknowledge some steps in the right
direction. However, I still don’t like this document TTC option and I firmly
believe that we would be better of removing this option from the document.

I acknowledge that the order has been changed, which sort of makes CTT the
primary option, even though not explicitly stated.

I also acknowledge the author’s extension to the security considerations
highlighting the danger of not understanding the function of TTC.

My main objection to TTC is that I think that all signature standards should
have a common basic approach to timestamps. For all other comparable signature
standards (CMS, XML, JOSE) any timestamp advertised in the signature metadata
IS a timestamp of the signature itself. Doing differently for COSE deviates
from signature standard praxis. And I think that is inherently bad and
dangerous.

It would be a completely different case if this would be common practice for
other signature standards. If that was the case, and this was proven to work
without creating security vulnerabilities in implementations, I would not
oppose. But this is not the case.

Even though I realize that the author’s probably has a usage in mind where this
is a very practical solution, and I trust the author’s that their usage will be
safe, I’m not convinced that all implementers will get this right. Even though
it would be less practical for the intended usage, I firmly believe that
timestamping of just payload data should be handled outside of signature
metadata (protected signature header). There are many ways to do it, less
generic of course, but safe.

If this document still proceeds with including TTC, then I would strongly
recommend a naming of the header parameter and option that is clearer about
what is being timestamped. TTC and CTT are not clear enough and could easily be
mixed up by an implementer.

I guess we have a deadlock here. I understand that the authors can’t see my
point and think my objections are unfounded. I on the other hand can’t see that
TTC is an appropriate option. I think it is dangerous, and no clarifying text
will likely change that. Perhaps the author's are just unlucky that I got
appointed as reviewer, but I have to say it as I see it.