John, In these cases are you carrying information in the JWS object other than the algorithm? I am trying to figure out if the "protected header" field is really used in this case.
Jim > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > John Bradley > Sent: Monday, August 19, 2013 12:49 PM > To: Justin Richer > Cc: [email protected]; [email protected]; jose issue tracker; > [email protected]; [email protected] > Subject: Re: [jose] #36: Algorithm "none" should be removed > > 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. > > What we call it I am flexible about, if it is a unsigned JOSE object in compact > serialization i am fine. > > John B. > > On 2013-08-19, at 12:30 PM, Justin Richer <[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]): > >> > >> 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] > > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
