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
