On 08/19/2013 05:46 PM, Richard Barnes wrote:
On Mon, Aug 19, 2013 at 5:27 PM, Justin Richer <[email protected] <mailto:[email protected]>> wrote:On 08/19/2013 04:17 PM, Richard Barnes wrote: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>Uh, no, it doesn't. In fact, it throws an error: java.text.ParseException: Invalid serialized plain/JWS/JWE object: Missing second delimiter at com.nimbusds.jose.JOSEObject.split(JOSEObject.java:222) at com.nimbusds.jwt.PlainJWT.parse(PlainJWT.java:99) at com.nimbusds.jwt.JWTParser.parse(JWTParser.java:61) From that very code you should be able to see that it plucks off the header and looks for the algorithm value, creating a "PlainJWT" object if alg=none.Ah, the risks of reading code. I stand corrected. At least the top-level parsing works, so you could just adapt the PlainJWT.parse() method.
So that would be the very definition of a breaking change.
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 "." characterI am too, but from the opposite end -- why is it so important for you to delete that single "." character?It's important that something that is not signed is does not pass JWS validation. If something unsigned is ever accepted as a valid JWS, then there's a huge downgrade risk.
I think that's a red herring. It's the same downgrade risk if someone sends alg:rot13 and your app doesn't want to accept that "signature" either. A JWS with alg:none should pass *only* if the signature field is empty, full stop.
-- Justin
-- JustinJohn 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
