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.




    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?

 -- Justin






    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]):
    >>
    >>  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

Reply via email to