- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Fri, 2 Nov 2018 16:59:37 +0100
- To: Chris Boscolo <chris@boscolo.net>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
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>> 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
Received on Friday, 2 November 2018 16:00:06 UTC