Dear Stefan,
please do not feel unheard. As you tried to highlight: yes we are
listening, but also have to take into account that timestamps that not
are not in the "bytes-to-be-signed" can be removed from a data object
and that really leads to variety of severe problems.
You explicitly highlight that:
TTC and CTT are not clear enough and could easily be mixed up by an implementer.
I think this is a point where we might disagree. I am at a loss how the
sequence of "Timestamp then COSE (aka sign)" can be in confused with
"COSE (aka sign) then Timestamp". I understand that developers are
always under pressure and deadlines and that standards text can be
confusing. But I cannot see how a reader of this spec can "mess this up"
unless... actually not reading the spec (which is why we reversed the
ordering to at least mitigate that case to some extend).
Basically, all co-authors are starting to be on vacation tomorrow (I am
the designated survivor before the summer hole) and they might chime in
with more feasible input when they are back.
I would have written a shorter reply, but I have to prep more food for
my vacation with kids,
Henk
On 31.07.25 17:04, Stefan Santesson via Datatracker wrote:
Document: draft-ietf-cose-tsa-tst-header-parameter
Title: COSE Header parameter for RFC 3161 Time-Stamp Tokens
Reviewer: Stefan Santesson
Review result: Has Issues
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.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
