Hi guys, In this heated discussion I find it hard to see any actual opposing arguments :)
People generally agree that plain (unprotected) JOSE objects have their legitimate use, e.g. in OpenID Connect request objects. If there's some confusion, that's perhaps because we have the unprotected JOSE objects defined in the JWS spec, instead in a spec of its own, e.g. "JSON Web Header" or "JSON Web Object". The Nimbus JOSE+JWT library enforces this distinction at the class level, by having separate classes for plain, JWS and JWE objects, and there have been only positive feedback from developers on this. The class hierarchy looks like this: abstract class JOSEObject PlainObject extends JOSEObject JWSObject extends JOSEObject JWEObject extends JOSEObject I understand that there can be several approaches to parsing and switching JOSE messages, be it top-level base64url segment counting and/or alg parsing. But even if parsing is sloppily implemented and a plain object is fed into a JWS parser, that would soon cause further processing to fail due to the missing signature segment. For software that only needs to route the messages without validating them, a simple examination of the dot delimiters and the surrounding base64url segments is sufficient, as people have pointed out. The third dot in plain objects is probably an remnant that we have from the spec or other association with JWSs, but that minor inefficiency is not a deal breaker for us. If there's mood in the WG to move plain objects into a simple separate spec I will support that. The general structuring of the JOSE objects however looks very good to me and I think the WG has done a good job with it so far. Vladimir -- Vladimir Dzhuvinov : www.NimbusDS.com : [email protected] On Mon, Aug 19, 2013 at 5:27 PM, Justin Richer <[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]> 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. 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 I 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. --Richard -- Justin 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 _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
