Re: JSON-LD vs JWT for VC

On Fri, Nov 2, 2018 at 9:49 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 11/2/18 12:15 PM, Anders Rundgren wrote:
> > I believe we who work with canonicalization schemes do not follow
> > here.
>
> To be clear, it sounds like the point that you and Chris are making is
> an argument against COSE, which is the direction the industry is going in.
>

To be clear, I have made no comments at all about COSE.

My view is as follows:

1) If we are going to stick with JSON as the data format for VCs, then we
should not head down the path that requires the whole world to update to a
new JSON parser that supports canonicalize.  Instead, just use JWT/JOSE
that is widely used today.

2) If we want to use a binary format, then my vote right now would be for
CBOR/COSE, but I reserve the right to change this view if presented with
compelling information/arguments.

I would rather go down the CBOR/COSE path than JSON with canonicalization.


> I'm pretty sure I know what you are saying, but rather than try to
> restate it, I'd like you and Chris to be more specific about the exact
> attack you're concerned with (rather than general security principles,
> of which many of us are aware of).


Alice:
Generate VC data()         -> [json_data]
Canonicalize([jason_data]) -> [packed_json_data]
Sign([packed_json_data])   -> [sig]
SendToBob()                -> [packed_json_data + sig]

Mallory:
AddExploit()               -> [buffer_madness + packed_json_data + sig]

Bob:
Canonicalize([buffer_madness + packed_json_data + sig]) ->
[packed_json_data]
    *BOOM* (modifies just the interal representation)
VerifySig([packed_json_data])   -> SUCCESS
Parse([packed_json_data]        -> [corrupt internal representation]

Instead, the first thing Bob should do is verify the signature of the exact
data that Alice produced. (For JWT, this is the Base64 representation of
the JSON.)  This greatly resduces the surface of attack that Mallory can do.

I want to state again, this isn't a RIGHT/WRONG argument.  I just prefer a
more defenseve style that has a hardended first step of processing that
checks the inputs and ensuring the the raw buffer is cryptographically
unmodified before starting to parse it. My view is probably biased because
I spent several years building an IPSEC stack...

If the community doesn't agree, then let's just move on.

   -chrisb

Received on Friday, 2 November 2018 18:39:37 UTC