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. 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. 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. The mode "Timestamp then COSE" (TTC) violates this propose by timestamping just the payload in a pre-signature process. 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. 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. 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. 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. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
