Re: JSON-LD vs JWT for VC

Please see my recent PR for IPLD and CBOR:

https://github.com/w3c/vc-data-model/pull/261 <https://github.com/w3c/vc-data-model/pull/261>


I argued my points in my recent Rebooting Web of Trust paper (draft) :

https://github.com/WebOfTrustInfo/rwot7/blob/master/draft-documents/ipld_did_documents.md <https://github.com/WebOfTrustInfo/rwot7/blob/master/draft-documents/ipld_did_documents.md>

sorry I couldn’t make to IIW.


Since both IPLD and JSON-LD are 100% compatible with JSON, the large number of JSON parsers and libraries are already available.

The only requirement in the VC model and DID-spec is to reserve “/“ for CID syntax with resolution over IPLD.


I don’t think we have fully committed to JSON-LD as the only approach for VC and DID. These are early days for DID and VC.


Manu,

The specific attacks include:

https://en.wikipedia.org/wiki/DNS_spoofing <https://en.wikipedia.org/wiki/DNS_spoofing>

https://medium.com/mit-security-seminar/eclipse-attacks-on-bitcoin-s-peer-to-peer-network-e0da797302c2 <https://medium.com/mit-security-seminar/eclipse-attacks-on-bitcoin-s-peer-to-peer-network-e0da797302c2>



I am also a fan of COSE rather than JOSE or JWT, see my comment in the JSON-LD spec:

https://github.com/json-ld/json-ld.org/issues/463#issuecomment-431191285 <https://github.com/json-ld/json-ld.org/issues/463#issuecomment-431191285>

Signing a serialized IPLD CID as CBOR provides a deterministic output and would be much more secure.


Pelle,

My issue with JWT is the lack of linking and the order of the JSON document changes the entire base64.
Linking using IPLD, serializing using CBOR then back out to JSON then encoding as base64 the JWT etc would be ok
 … but you then need self-describe the payload the output you got so it can be validated and there should only be one way of doing it.



Also, see my PR for DID-spec:


https://github.com/w3c-ccg/did-spec/pull/110#issuecomment-431534081 <https://github.com/w3c-ccg/did-spec/pull/110#issuecomment-431534081>




Best,

jonny



> On Oct 29, 2018, at 5:20 PM, Chris Boscolo <chris@boscolo.net> wrote:
> 
> 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.
>