Subject: [COSE] Why you shouldn't have your crypto designed by a CEO

From: Carsten Bormann <[email-masked]>
Date: Fri, 7 Jan 2022 16:03:28 +0100

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

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 7 Jan 2022 12:37:00 -0800

Given the vast hype and dollars around “crypto” these days it’s no surprise stuff like this is happening.  Was interesting to read.

More and better implementations of COSE would probably make a big difference in its deployment. I’m trying with t_cose, but it would be cool if OpenSSL and Bouncy Castle supported COSE the way they support CMS. 

It would be helpful if there were some really good apps that helped pull COSE through. Some are coming, but it is a bit slow. CMS got a lot of pull through from PKCS7 and S/MIME.

LL

> On Jan 7, 2022, at 7:03 AM, Carsten Bormann <[email-masked]> wrote:
> 
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 10 Jan 2022 06:05:27 +0100

Hi Carsten,

Although I'm a huge fan of standardization, it doesn't always work that great in practice.

A recent example is W3C's effort, "marrying" WebAuthn with payments, called Secure Payment Confirmation (SPC). In turns out that the WebAuthn folks(≈IETF) have quite limited experience of the application area, leading to a design having pretty horrible User-, Deployment-, and Privacy-characteristics.

It doesn’t take a degree in computing to realize that this standardization activity have set their own “standards”: https://github.com/w3ctag/design-reviews/issues/675#issuecomment-964273692

In fact, "industry-standard" [*] features such as Authorization and Encryption/Tokenization were never considered.

How did this happen? Well, since this effort was initiated by Google (rather than by a CEO from some obscure company), questioning it becomes awkward and could also negatively affect other W3C and IETF work, typically carried out by the very same lot.

However, it doesn’t stop there.  If this project had considered evolving on-line payments by for example defining on open standard along the lines of Apple Pay, the tensions would have reached an unmanageable level since a successful launch would most likely spell the end of both Apple Pay and Google Pay.  Note that this is an internal (self-inflicted) problem; the “market” certainly doesn’t care 😊

That Google also have close to a monopoly on browser technology makes the situation even more complex.  In practical terms it is impossible for ANYBODY creating an alternative since there is no way getting it to the market.

Cheers,
Anders

*] EMV: currently powering 10 billion crypto-enabled payment cards.  EMV is also the foundation of Apple Pay.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 11 Jan 2022 09:46:38 +0000

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-masked]> On Behalf Of Carsten Bormann
Sent: Friday, January 7, 2022 4:03 PM
To: cose <[email-masked]>
Subject: [COSE] Why you shouldn't have your crypto designed by a CEO

Grüße, Carsten

_______________________________________________
COSE mailing list
[email-masked]
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.