Re: JSON-LD vs JWT for VC

On Thu, Nov 1, 2018 at 11:51 PM Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> On 2018-11-02 07:28, Chris Boscolo wrote:
> >
> > On Thu, Nov 1, 2018 at 8:51 AM Dave Longley <dlongley@digitalbazaar.com
> <mailto:dlongley@digitalbazaar.com>> wrote:
> >
> >     On 10/29/2018 06:20 PM, Chris Boscolo wrote:
> >      > IMO, it just seems unsafe to allow data that has been signed to be
> >      > modified in any way and still produce the same signature.
> >
> >     Could you give a concrete example for how this is related to
> >     canonicalization? This sounds like a general problem with any
> signature
> >     system -- and I think we all would agree that different data should
> hash
> >     differently and produce different signatures.
> >
> >
> > To be clear that particular comment isn't criticizing that
> canonicalization needs to be done, it is criticizing that it needs to be
> done prior to verifying the signature. It was in response to Manu's comment
> that the JSON can be modified with whitespace after it has been signed.
> >
> > I don't want to overstate this, I'm not suggesting that this a fatal
> flaw. I just think it is a poor security architecture to allow the data
> that has been signed to be modified after signing and require that receiver
> of the data to run it through a canonicalization process prior to verifying
> the signature.  It opens a door to exploits of the canonicalization process
> by a man-in-the-middle.
>
> This seems to me like a completely generic computing problem. If the
> receiver's system is broken and vulnerable to input data errors all bets
> are off.
>

It's not a geeneric computng problem, it is best practices when building
cryptographically secure protocols.


> It is bit in the same veins as the claim that an intermediary setting the
> JWS signature algorithm to "none" opens a security hole [1].  It does not,
> a receiver MUST always define a policy and if the input doesn't meet that
> policy, the message is rejected.  Leaving an application's policy to a
> general purpose library is based on a misconception.
>

Exactly!  This problem resulted from the fact that the parameters
describing the way the data should be protected are not part of the
signature/hmac.  A couple decades of building security software have taught
us some best practices, why would deviate from them with new proposals?

   -chrisb