Reviewer: Hannes Tschofenig Review result: Not Ready Upfront I have to say I am a bit fan of the work the authors, Mike and Tobias, are doing in general. This document, however, does not meet my expectations of what they have published in the past. I am sorry to say it but the entire document is based on flawed assumptions. There is a good reason to put meta-data for signing and encryption into a header while the actual payload, to which the security protection is applied to, is separated into the body. Where is the trend suddently coming from to put payload content into the header, or (in related work) to place content that should be in the header into the payload? There are two arguments given in the introduction for why there is a need to copy content from the payload into the header: 1. This feature is also available for JWTs, and 2. The payload may be encrypted and hence the recipient first has to decrypt it to see the plaintext value. Ad (1): It is not a good argument for me to also include this feature in CWTs. I would even drop the feature in JWTs. Ad (2): When content is encrypted then the idea is that sender would like to hide it from intermediaries and to only make it accessible to the recipient. Copying the plaintext values subsequently into the header isn't a great idea. Is this a way to apply encryption only to some values rather than others? Why cannot we demand from applications that use CWTs and JWTs that they perform the security processing first and then look at the payload for whatever they need? Why do we have to replicate content for faster and more convenient processing? What is also not said in the document is that copying otherwise protected content into the header introduces security vulnerabilities because developers will make security-related decisions BEFORE they process signatures, MACs or the encrypted payloads. Will this happen? Of course, it will. Please have a look at https://datatracker.ietf.org/doc/draft-tschofenig-jose-cose-guidance/. Even on a smaller scale (with the key id) this already creates problems for developers of COSE / JOSE libraries because the layers get combined and important security decisions are outsourced to the developer. We know that developers, who use these libraries, are unable to make good security decisions. While the draft content is quite simple - almost innocent looking (namely just mapping the claims registry into the header parameter space), I fear the solution just covers up bad design choices made by some applications using CWTs and JWTs. At a minimum I expect the use cases to be better explained. Under what circumstances is it a good idea to even consider this approach as a developer? I know that most developers don't read RFCs - they look at libraries and examples. Hence, we have to talk to developers of libraries to find out if they are able to write their libraries such that they can be safely used. What is the value of libraries written in language like Rust or F* when the developer can, with a small mistake, shoot themselves into the foot? -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
