- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Wed, 2 Dec 2020 21:18:04 -0500
- To: Gabe Cohen <gabe.cohen@workday.com>, "public-credentials@w3.org" <public-credentials@w3.org>
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
Received on Thursday, 3 December 2020 02:18:21 UTC