It is accepted. That doesn't mean that the application should accept it unless
it validates that the actual algorithm used meets its security requirements,
whether it's "none", or not. (For instance, if you require HS512 or ES512,
your application will need to reject inputs that used HS256, etc.) This is a
basic requirement for secure applications - not a new requirement created by
the presence of "none".
-- Mike
From: Richard Barnes [mailto:[email protected]]
Sent: Monday, August 19, 2013 1:21 PM
To: Mike Jones
Cc: John Bradley; Justin Richer; jose issue tracker; [email protected];
[email protected]
Subject: Re: [jose] #36: Algorithm "none" should be removed
But that signature is valid for that algorithm. So a generic JWS parser will
show it as accepted.
On Mon, Aug 19, 2013 at 4:18 PM, Mike Jones
<[email protected]<mailto:[email protected]>> wrote:
Having an empty signature segment already makes it recognizably different.
From: Richard Barnes [mailto:[email protected]<mailto:[email protected]>]
Sent: Monday, August 19, 2013 1:18 PM
To: John Bradley
Cc: Justin Richer; jose issue tracker; Mike Jones;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: Re: [jose] #36: Algorithm "none" should be removed
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>
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
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]<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
