Re: JSON-LD vs JWT for VC

On 2018-11-02 17:10, Mike Lodder wrote:
> The point that Chris is making I agree with. If you can alter the data after a signature has been computed in anyway this is considered a big NO NO by many security personnel.

I believe we who work with canonicalization schemes do not follow here.
If your canonincalization doesn't do exactly what it should, signature validation fails.
That is indeed a nuisance, but not a security problem.

Anders

> 
> On Fri, Nov 2, 2018 at 10:01 AM Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
> 
>     On 2018-11-02 16:02, Chris Boscolo wrote:
>      >
>      >
>      > On Thu, Nov 1, 2018 at 11:51 PM Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com> <mailto:anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>>> wrote:
>      >  >     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?
> 
>     You mean JWS and LD-signatures do not protect such data?
> 
>     I believe this is incorrect, at least for JWS.  That the "none" algorithm doesn't secure anything is for sure but the use-case for "none" is simply keeping unsigned messages in the same (ugly) format as signed ditto.
> 
>     Enveloped signatures (https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-01) do no suffer from this problem, although some people claim that you can just remove the signature element to fool the receiver into accepting something it should not.  That's what application policies deal with.
> 
>     Anders
> 
> 
> 
> 
> 
> -- 
> Mike Lodder
> Security Maven
>

Received on Friday, 2 November 2018 16:15:51 UTC