Re: DeCanonicalization: (was JSONWebSignature2020 vs JcsEd25519Signature2022)

On Sat, Jan 28, 2023 at 2:41 AM Anders Rundgren
<> wrote:
> Although I'm one of the designers of JCS (RFC8785), I got slightly tired of the disapproval by the IETF security elite who insist that neither XML Dsig, nor schemes based on JSC work (*).  "Canonicalization is an altogether bad idea".

Yes, the knee-jerk reaction to canonicalization among a minority of
loud opinions at IETF is a problem. I've found that those that
disapprove the loudest are parroting things they've heard other more
knowledgeable people say, but when pushed, barely have any experience
in the canonicalization space, so they back off to extreme statements
like: "Canonicalization is an altogether bad idea" (because they don't
know any better).

The Wireguard folks spoke of this "allergic reaction by security
experts" to some of their kernel security work. Namely around the
downsides of algorithmic agility. They eventually prevailed and got
the zero-agility/zero-optionality approach into the core Linux kernel
after they got past all the FUD and "90s cryptography thinking":

Meanwhile, other canonicalization schemes, like the one used in HTTP
Signatures, tend to sail through large groups like the HTTP WG where
these "All Canonicalization is bad" folks haven't been able to block
the work.

The same goes for JCS, good for you for getting it through IETF,
Anders. I applaud your effort in that space and remember watching you
go through the IETF gauntlet of security naysayers. JCS is a simple
and straightforward canonicalization mechanism for JSON and is a
textbook example that not all canonicalization schemes are "needlessly

> Due to that I gave up on my baby (JCS)

Yep, IETF security culture at work. Granted, that sort of bullying
isn't mainstream in IETF, but when it happens, it harms contributors.
There are many supportive people at IETF, and the most knowledgeable
tend to be the most open to discussing the nuances and trade-offs.
It's just hard to get past the naysayers and they tend to be overly
dismissive, parrot talking points, and don't always operate on facts
and testable hypotheses.

Deterministic CBOR is a path forward for a number of important use
cases. Our organization couldn't use it for a number of Verifiable
Credentials use cases because the base data format is JSON-based  (not
CBOR-based) and it's useful to have serialization agnostic signatures
so you can hop from JSON to CBOR (or any other compatible
serialization) and back... which is a feature that's being used in
deployed systems today (TruAge).

I just wanted to take a moment to validate what you're saying, Anders.
That's been our experience as well, but luckily some of those caustic
individuals have moved on since then. :)

-- manu

Manu Sporny -
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)

Received on Monday, 30 January 2023 19:17:42 UTC