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. On Fri, Nov 2, 2018 at 10:01 AM Anders Rundgren < 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>> > 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 MavenReceived on Friday, 2 November 2018 16:11:54 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:50 UTC