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>
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
>
>