Re: JWS Clear Text JSON Signature Option (JWS/CT)

+2.5, at least. I couldn’t have expressed it better myself.


Ø  It turns out that managing the

Ø  perfectly extensible but fragile, picky alignment of rigorous semantics has

Ø  a cost, and not everyone wants to pay it.

The “my way or the highway” sentiment is really quite detrimental to progress here. The advice is not “dangerous.” I give more agency to software engineers and their teams to do research and come to a well-reasoned conclusion. Not all enlightened VC engineers will reach the same conclusions.

We need to have a clear enumeration of viable options with clear tradeoffs. As Daniel stated, there is plenty of evidence of both systems are viable and have significant buy in.

Gabe

From: Daniel Hardman <daniel.hardman@evernym.com>
Date: Wednesday, December 2, 2020 at 9:26 PM
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: Gabe Cohen <gabe.cohen@workday.com>, public-credentials@w3.org <public-credentials@w3.org>
Subject: Re: JWS Clear Text JSON Signature Option (JWS/CT)
>If folks want to push for JCS, they're going to have to do way better
than "your business doesn't necessitate the use of the features it offers".

I disagree. I think you're being overly categorical in asserting the importance of semantic alignment, and you're not acknowledging the value of looseness. (For the record, I'm not claiming looseness is *better* than super careful semantic alignment -- I'm just claiming it's a perfectly valid tradeoff, and not as sinister as you're painting it.)

Software developers have wrestled the tension between tight semantic alignment and looseness as the web has matured. Most of us who were building web tech in the 90s started out with the detailed, careful alignment offered by SOAP, WSDL, and XML namespaces. The paradigm with this approach is much like the worldview you're advocating, Manu. Then duck-typed JSON surfaced in RESTful web services and took the world by storm. Developers who switched approaches were making a calculated tradeoff, not exhibiting casual stupidity. It turns out that managing the perfectly extensible but fragile, picky alignment of rigorous semantics has a cost, and not everyone wants to pay it. I think the market has now weighed in on which version of this tradeoff is considered more attractive most of the time.

Now, I anticipate that you might say, "Yes, but that's for ordinary data. With *verifiable* data, the stakes are higher, so tight alignment is more important." There's probably some truth to that. But I claim that *how much* truth is debatable. Personally, I don't find it hard to align on the meaning of JWTs, even though they lack some of the semantic rigor you're advocating. An awful lot of good security is enforced with them. And I think the semantics-based attacks you're worried about are small potatoes compared to dozens of other gaping cybersecurity holes in our ecosystems that I'd much rather plug right now.

In essence, what I'm saying is that I think an open world approach can be highly functional and secure with "good enough" semantic alignment, and that it's perfectly rational to define "good enough" contextually. I don't believe it's binary.

On Wed, Dec 2, 2020 at 7:20 PM Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>> wrote:
On 12/2/20 6:44 PM, Gabe Cohen wrote:
> One should choose to the non-LD version when the complexity of LD is
>  not worth any of its features, or your business doesn’t necessitate
>  the use of the features it offers.

Imagine giving that advice to a software developer that is unfamiliar
with the cryptographic choice in front of them. We've seen seasoned
software developers choose poorly given that advice. The likelihood of a
less seasoned software developer doing the wrong thing given that advice
is much higher, which makes it dangerous advice.

That is why you shouldn't use JCS without a number of other protection
mechanisms in place... and knowing what protection mechanisms to put in
place requires a lot of knowledge about the sort of attacks you can do
against JCS. The vast majority of software developers don't have that
sort of knowledge, which is why JCS is dangerous in most developers hands.

We've been working in this community for a very long time attempting to
make sure the systems we're building "fail closed". For those not
familiar with that term, you can think of it in terms of what you would
want a lock that is protecting your home to do when someone tries to use
the wrong key with the lock. You want the door to "fail closed" -- that
is, when in doubt, the lock should keep the door closed. This is
different from "fail open" systems, like fire safety doors. Fire safety
security doors remain actively and magnetically locked as long as there
is power to the door, but if something goes wrong, you want those doors
to "fail open" so everyone can get out of the building.

The same "fail closed" (aka "fail to verify") requirement is there for
digital signatures and the information that the digital signature is
protecting. If someone tampers with a single bit of information, you
want the system to "fail closed/fail to verify". This is even more
important in open world information models, like Verifiable Credentials.
You don't want the signature to verify if there is misalignment at the
digital signature level (bytes) OR at the information model level (meaning).

Most Linked Data Signature formats ensure alignment at the digital
signature layer AND the information model layer.

JCS is the only Linked Data Signature format that does not ensure
alignment at the information model layer. So, it'll work 99% of the
time, except when it doesn't, and when it doesn't -- there's an attack
vector there waiting for someone to exploit.

If folks want to push for JCS, they're going to have to do way better
than "your business doesn't necessitate the use of the features it offers".

What is the concrete checklist that an unseasoned software developer can
go down that ensures that they will use JCS correctly? The issue there
is that the best answer I've seen is "it depends on your use case".

There is no such checklist required for non-JCS Linked Data Security
Suites because those systems fail closed, which is what, IMHO, we should
all be striving for.

-- manu

--
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches<https://urldefense.proofpoint.com/v2/url?u=https-3A__tinyurl.com_veres-2Done-2Dlaunches&d=DwMFaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=8q0wrOfH-XtkquJe3zZvbZIZ4Fdjh_ScTjE6H3xw59k&m=cKLkn5te-Sh89SrEf_mGTJBYNAgkrl0kog1nmS_kuFA&s=KN4Y-RN0DP8sKdCVGkLreho7gf_UjsImxR_Q6qiQOy8&e=>