Having an empty signature segment already makes it recognizably different. From: Richard Barnes [mailto:[email protected]] Sent: Monday, August 19, 2013 1:18 PM To: John Bradley Cc: Justin Richer; jose issue tracker; Mike Jones; [email protected]; [email protected] Subject: Re: [jose] #36: Algorithm "none" should be removed
On Mon, Aug 19, 2013 at 3:48 PM, John Bradley <[email protected]<mailto:[email protected]>> wrote: In OAuth and Connect there are cases where you are receiving tokens from multiple sources. By allowing none as a alg option we can process signed or unsigned tokens with the same basic handler by inspecting the first segment. I note currently that while none has three segments the last segment must be empty. I think that is sufficient to keep people from becoming confused. Making it two segments will break existing parsers for no good reason. No, there's a very good reason. Something that is not signed should not be accepted as a JSON Web Signature object. Acceptance of a JWS implies that the payload and protected headers were integrity protected from the signer; that is not true for "alg":"none". Also, it's not clear that this change will break existing parsers. For example, the NimbusDS parser would successfully parse a two-segment object as a "plain JWT" <https://bitbucket.org/nimbusds/nimbus-jose-jwt/src/ca58ff0ece35243aa6546583dffcd236dcea26d2/src/main/java/com/nimbusds/jwt/JWTParser.java?at=master> What we call it I am flexible about, if it is a unsigned JOSE object in compact serialization i am fine. I would also be completely fine with an unsigned "header + content" structure (though I don't think it adds any value). But it must be recognizably different from JWS. --Richard, who is honestly kind of floored that there's all this argument over a single "." character John B. On 2013-08-19, at 12:30 PM, Justin Richer <[email protected]<mailto:[email protected]>> wrote: > I don't normally jump into the discussion on this list, but I've been using > the output of JOSE for quite some time now and am a committer on the NimbusDS > JOSE JWT library. However, with tonight's call coming up (which I won't be > able to make) I wanted to jump in and say that from my perspective, alg:none > makes a lot of sense. There's a need for being able to send unsigned content > with JOSE objects, and that's been pretty well established by others on the > list here. As an implementor, though, I think it makes the most sense to have > the unsigned content be parallel in structure to the signed content. When > reading a string and constructing objects, our library parses the header and > dispatches the parser based on the "alg" parameter. > > And as Mike points out, alg:none has been in the spec as required to > implement for ages now, and it hasn't caused the horrible security holes that > people are predicting. > > -- Justin > > On 08/01/2013 07:23 AM, jose issue tracker wrote: >> #36: Algorithm "none" should be removed >> >> >> Comment (by [email protected]<mailto:[email protected]>): >> >> And sure enough, working groups across the IETF are having to explicitly >> forbid the use of null ciphersuites. They provide empirical evidence that >> this design pattern is a bad idea. >> >> As I've pointed out before, you can add that verification algorithm, but >> you will not have a good time writing security considerations around it. >> Checking that you support "none" is not enough -- you have to check that >> *nothing* *else* in the header could possibly indicate that a different >> signature algorithm should be used. >> >> So we have something that (1) causes a lot of spec work, (2) causes >> security vulnerabilities under likely implementaiton designs, and (3) has >> no use case, and (4) will haunt us for years to come (how many times do >> you want to write 'MUST NOT use "alg":"none"'?). Sounds like a recipe for >> success! >> > > _______________________________________________ > jose mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/jose
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
