Reading my own reply, I think I can frame this even shorter and clearer:
Why advertise a timestamp that has nothing to do with the signature in
the signature header?
It does not belong there.
And if you stick it there anyway, people may think that it actually has
something to do with the signature.
And that is the source of potential confusion.
/Stefan
On 2025-08-01 02:11, Stefan Santesson wrote:
Hi Henk
Thank you for providing your view. The only thing that is a bit
confusing to me is that we seem to have a binary disagreement, rather
than a discussion of severity.
By binary disagreement I mean the fact that I point out a problem, and
your position is to deny its existence entirely.
Quote:
"I am at a loss how the sequence of "Timestamp then COSE (aka sign)"
can be in confused with "COSE (aka sign) then Timestamp"."
That to me is fundamentally different from you saying. Yes, I see the
issue, but I don't think it is likely, or serious enough to fix.
(Which would be easier to understand)
I think I have gone to length of describing exactly how such confusion
could occur. To recap that shortly. We often have different developers
working on different parts of a system.
- One developer could make the code that signs the document
- A second developer could make the code that parses signatures and
deliver time stamp results in a suitable structured data class
- A third developer could make the code that process the structured
data class and use timestamp time to validate the certificate path.
Here is potential of confusion between the developers. The error is
most likely made by the third developer that possibly looks into the
structured data class and find a "TTC" timestamp, extracts the time
and use it for the wrong purpose, with the false belief that it
represents a time when the signature existed.
When you say that you cant see how this is possible, I'm not sure I
understand what you mean.
- Do you think such scenario is impossible?
- Or do you mean that any developer parsing the signature (the second
developer) who read your standard and implements it, could not
possibly misunderstand your text?
If it is the latter, then I tend to agree with you. The second
developer most likely gets this right. Its the third developer I'm
worried about.
This risk would be eliminated if the TTC timestamp is never referenced
in the signature metadata (header) at all, and thus never appears in
some signature validation result data class produced by developer 2.
My experience of developers makes me fear that this type of confusion
is pretty likely. Most will get this right, but some won't. No other
signature format does TTC and advertise it in signature metadata. Why
then should COSE do it? That is the million dollar question. Why
advertise something in a signature header that has absolutely nothing
to do with the signature? It does not belong there.
Now as stated before. I have no stake in this. I will not fight this.
But as long as I'm asked to state my opinion about this, it will
likely be the same.
/Stefan
On 2025-07-31 17:22, Henk Birkholz wrote:
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
