Re: DeCanonicalization: (was JSONWebSignature2020 vs JcsEd25519Signature2022)

On Sun, Feb 5, 2023 at 1:17 AM David Waite <dwaite@pingidentity.com> wrote:
> The challenges in retrofitting a canonicalization and signature system over HTTP are significant, and (again, in my opinion) saying http signatures are "sailing through" does a disservice to others involved in that work.

I was the primary editor for and incubated the HTTP Signatures
specification for about a decade before it went standards track in the
IETF HTTP WG. I'm the one that worked with Mark Cavage, who worked as
a Senior Software Engineer Amazon Web Services and then as the VP of
Engineering at Joyent at the time, to get his approach down into spec
form and then worked with implementers to get implementations. Let me
try and shed some light on some of the assumptions made in your email,
since I was there.

The technical challenges around canonicalization were NOT significant.
It was a largely mechanical process. Both Mark, Dave Longley, and I
were trying to create an alternative to this insanity that was having
to manage symmetric secrets and access tokens.

I am also exceedingly thankful that Justin Richer and Annabelle
offered to lead the work through the IETF. They have both done a
phenomenal job of making it better and aligning it w/ modern HTTP
header encoding schemes.... but again, no big technical breakthroughs
had to happen for canonicalization in HTTP to be a thing.

People need to stop believing in this completely self-defeating
attitude of "canonicalization is bad / too hard", especially since
it's been demonstrated to not ALWAYS be hard. You can paint yourself
into a corner, and I guess that's what happened with XML
Canonicalization, but that doesn't seem to be true for JSON
Canonicalization, HTTP Message Header Canonicalization, nor RDF
Canonicalization (which DID require several breakthroughs, with huge
thanks and accolades to Dave Longley who made it happen over a very
tough 3-6 months of R&D).

Canonicalization is a tool. Sometimes you need it. Sometimes you
don't. If it solves a problem you have, great. If it doesn't -- don't
use it. However, going around trying to convince us that we shouldn't
have the tool at all, or misrepresenting problems with the tool --
well, that's the real problem, here.

Mark noted that he wanted nothing to do with the standardization
process because of the time and mental energy it takes to navigate all
of this. It is exactly this knee-jerk reaction from experts in one
area, commenting about another area of which they are not experts,
that is the problem.

The biggest challenge around canonicalization, and the thing that has
taken the most amount of effort and time over the years, is combating
the myths around the technology. It's the asymmetric sniping that
requires the critics to just throw (typically) baseless accusations
into the conversation, which the implementers then have to respond to
over and over again. It's one thing for a well constructed argument
with data to be put forth -- that's great, that's constructive and
improves things... unfortunately, that's almost always NOT what we
get.

It's a problem because of exactly what Anders experienced w/ JSON
Canonicalization Scheme at IETF... he "gave up on his baby"... not
because it was technically difficult or not possible to do, he did it
(partly) because of unconstructive naysaying and toxic engineering
culture. He saw that a loud minority of people were just going to
poison the well, so he moved on (but luckily created a foundation for
the rest of us to build on). A number of us working on
canonicalization have experienced this dynamic over the years... what
the RDF Dataset Canonicalization folks experienced at W3C (and
IETF)... and what we experienced in the early days of HTTP Signatures.

This constant drum beat of "canonicalization is bad" by non-experts
harms innovation in the space. It's a good thing those working on it
are so determined, but we shouldn't discount the number of good people
that we lose along the way that do not have the mental bandwidth for
the standards politics. I'm sure the CL Signatures folks and the
DIDComm folks feel this to a certain degree as well (though, that's a
third rail I'm trying not to touch in this very specific discussion
around canonicalization).

I hope this helps clarify that I'm not discounting the work that
everyone put in on HTTP Signatures to get down the standardization
track. What I'm pointing out is that 1) canonicalization isn't always
a hard technical problem, and 2) the hard problem is usually the
standards politics around it, and 3) the standards politics are
typically created by non-experts in canonicalization, and 4) we lose
good contributors because of this dynamic.

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
https://www.digitalbazaar.com/

Received on Sunday, 5 February 2023 17:42:22 UTC