Re: JSON-LD vs JWT for VC

Anytime a message can be modified and result in the same signature is very bad. This means you can't trust the data because it could be any number of possible things.

If that is the case the implementation is bad or the crypto is bad. We've seen cases where even experienced crypto engineers get it wrong. Look at RNCryptor V1 for Apple and iMessage.

I'd love to have this fixed and help but I may not be understanding everything going on here.

________________________________
From: Chris Boscolo <chris@boscolo.net>
Sent: Monday, October 29, 2018 4:20:49 PM
To: msporny@digitalbazaar.com
Cc: public-credentials@w3.org
Subject: Re: JSON-LD vs JWT for VC

Manu,
To be clear, I'm not calling into question yours or any other member of this group's experience with cryptography. (Tho, it's worth pointing out that the number of downloads has little bearing on whether the implementation has no critical vulns. Heartbleed has proven this.) I mention my own experience only because I am newer to this group, and I don't want you to assume that I don't have this same experience.

My concern is the following:

I have a JSON-LD doc, call it VC1, that after canonicalization hashes to XYZ.
If there are any vulnerabilities in the parser, perhaps a strange buffer overflow, I *may* be able to modify VC1, call it VC2, so that it also canonicalizes and hashes to XYZ, but when queried returns different values than expected due to the buffer overflow.
IMO, it just seems unsafe to allow data that has been signed to be modified in any way and still produce the same signature.

   -chrisb

On Mon, Oct 29, 2018 at 2:22 PM Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>> wrote:
> BTW, as one who has developed protocol-level encryption software, the
> comment "ability to add non-signature-destroying whitespace" makes me
> cringe.  It seems like it is just needlessly opening the door to a
> new attack vector.

Note that we have experience writing cryptography / digital signature /
encryption software that is broadly deployed as well (several million+
installs per week)... so, I'm asking this question from that perspective:

What's the specific attack? The details matter.