Hi,
I guess most authors are likely still on vacation.
I wanted to say I do agree with Stefan. As an implementer I can totally see people mixing up TTC and CTT.
Can the authors think about using different terms or acronyms for this?
Paul
On Thu, Jul 31, 2025 at 8:22 PM Stefan Santesson <stefan@xxxxxxxxxxx> wrote:
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
