Hi Stefan, Thanks very much for your review. On Fri, 14 Mar 2025 at 00:25, Stefan Santesson via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Stefan Santesson > Review result: Serious Issues > > I have some issues with this document of various severity. > > Use cases: Timestamping of signed documents is normally only relevant > for documents that are processed and trusted over a long time. It is > generally not useful for interactive protocol exchanges, where the > signed data includes necessary elements for asserting that the data is > fresh and not a replay. > > The nature of the COSE signature is naturally optimaized for use in > protocol exchanges rather than those use cases that needs time-stamp > protection. Maybe. This doesn't prevent COSE-signed objects from being utilised in other contexts. There's a growing ecosystem of applications that use COSE to secure their messages - e.g., SCITT and RATS among others - where signatures can be applied to objects that have long-term archival requirements (e.g., for auditing). > It would be useful if the Introduction could highlight in what cases > COSE is a natural choice for the types of documents that actually > benefit from timestamping. Section 1.1 (use cases) was intended to address this matter. If the current content is insufficient, could you please suggest some additional text? > Purpose of time stamping: When timestamps are added as part of the > signed object, it has the purpose of asserting the time when the > signature is created. This is essential to meet the security goal to > ensure that the signature was not created with compromised > credentials. OK, that is one use of timestamping, which is covered by CTT. > The mode "Timestamp then COSE" (TTC) violates this propose by > timestamping just the payload in a pre-signature process. I wouldn't frame this in terms of "violation". Instead, TTC implements a different (legitimate, in my opinion) use pattern than the one covered by CTT. > I argue that this mode has nothing to do with COSE. This is purely > timestamping of some data before being signed and I struggle to see > that it is appropriate to put such time stamp in a COSE header, as it > has nothing to do with the COSE signature. Sorry, I don't understand. If the signature also covers the timesatmped data, it has everything to do with the COSE signature. > It is also of questionable value to add this as a protected header. > The TST is signed by itself and cryptographically bound to the signed > payload. I struggle to see what the benefits are to have it protected > by the COSE signature. By incorporating it into the header, we provide a way to tightly wrap all the associated things together. I see no compelling technical reason against adopting this approach. Given that the current design is the consensus of the COSE WG, I would prefer to leave it as-is. > Security threat with pre signature timestamping (TTC). I'm worried > that the timestamp created before signing can be misunderstood by > implementers to mark a time when the signature was created. This worry > is increased by the fact that this is the way time stamps provided in > signatures normally work. If this would be the case, it would be > possible to fool such verifier by stealing a signed document with a > timestamped payload before key compromise and resigning it with a > compromised key. > > At a minimum, this should be highlighted in the Security > Considerations, which is silent on the topic. The implementer is presented with two choices, each with well-defined security properteis. Certainly, we can always add more prose to explain the implications of these choices for implementers. Again, if you think the current text is lacking, we are happy to incorporate your suggestions. > Requested change I would recommend to remove the TTC mode timestamp > altogether. If a time stamp is required of the payload data only, this > should not be a COSE header as it has nothing to do with COSE. This > also removes potential security issues cased by implementers not > understanding fully that this timestamp has a completely different > security context than CTT. > > It seems to me that the CTT mode does everything that TTC does, just > better. It does, except when the application flow is such that the signer has already obtained a timestamp before sending it through the COSE machinery. If we drop CTT, this usage pattern will not be addressed, and that would be a loss of functionality. cheers! -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
