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

[Anders Rundgren <[e-mail]>]

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.

On 2022-01-07 16:03, Carsten Bormann wrote:
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cose