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 <[email protected]> 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. > >>> > >>> > >>> >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
