- From: Chris Boscolo <chris@boscolo.net>
- Date: Fri, 2 Nov 2018 11:39:01 -0700
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
- Message-ID: <CAByYRhZ5TTdz7SoiEjeyL=B-7TuZqbs3iuq=oSBQ6UG8aehV0A@mail.gmail.com>
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