Hi Carsten, it is annoying that engineers create alternative solutions primarily for their own marketing benefit (with collateral damage). However, this is not a new development. We even see this happening inside the IETF as well. How often do we have the situation where someone wants to gain a marketing benefit by writing a new spec that serves the same purpose as an existing one?
Referring to proprietary specifications as "standards" is not new either. There is no change to the JOSE / COSE specs that would convince this company to use them because they anticipate business benefits from developing something from scratch. Ciao Hannes -----Original Message----- From: COSE <[email protected]> On Behalf Of Carsten Bormann Sent: Friday, January 7, 2022 4:03 PM To: cose <[email protected]> Subject: [COSE] Why you shouldn't have your crypto designed by a CEO In the IETF we focus on making building blocks, which are then used to create products and deployments. Personally, I generally focus on creating quality building blocks and try to ignore whether those ultimately lead to design wins or not. But I can’t help seeing a whole little industry creep up that is interested in creating alternative building blocks that appear to be of interest to the creators so they can attain control over them and perform rent seeking from that control. This is, of course, an old game in standardization, but it is reaching new heights in the area of standards for signing things. Under the guise of writing tutorials about this subject field, IETF building blocks are disparaged and the “new” wares are peddled instead. Within the bubbles created by this, it may seem the IETF standards are done with and the “alternatives” can be presented as the way to go. Marketing is a necessary component of technology development, but it should not be built out of hatchet jobs and, er, alternative facts. For those looking for an example, try exhibit [1]. After a brief tutorial (which is always welcome), various approaches are discussed. JOSE (with JWS and JWT) is correctly presented as the “elephant in the room”, but then immediately disqualified because of the single misfeature that JOSE stores the algorithm identifier with the signature. The author mentions RFC 8725, but either hasn’t read it or doesn’t want to mention that this immediately deflates his only(!) argument against JOSE. Note that exhibit [1] is from August 2021, but doesn’t even mention COSE. Probably because COSE is a convincing successor to JOSE in the space he is targeting, with implementations out there that have taken lessons from early JOSE implementations. Instead, the piece presents [2] as evidence that “PASETO is progressing toward an IETF standard”, but then quickly deflects any potential response that it isn’t, by saying "it is important to note that [IETF] acceptance does not really matter from a security perspective" ([2] itself says the same thing in other words as well). Of course, he later argues against crypto agility, “any of the SHA-2 functions are fine. Pick one and use it everywhere, don’t try to design in agility at the protocol level”. I’m going to spare you from further analysis of this pamphlet and will only add [3] as a link offering a probably explanation why this piece was written. I’m wondering whether we (the set of individuals interested in this, certainly not the WG as an IETF construct) need do to more in offering factual material to the channels that are being used for this “marketing”. Grüße, Carsten [1]: https://dlorenc.medium.com/signature-formats-9b7b2a127473 [2]: https://github.com/paseto-standard/paseto-rfc [3]: https://chainguard.dev/posts/2021-10-07-introducing-chainguard _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
