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
