For both of these cases, wouldn't having alg:none in the header be the
only way to be consistent with unsigned content across both the compact
format and the JSON-based format? Or am I missing something?
-- Justin
On 08/19/2013 03:14 PM, Phil Hunt wrote:
From a consistency perspective:
a. There are those that see everything as JWT tokens so a
signature=none makes perfect sense for consistency
b. There are those that see everything as JSON. JWT is seen as the
edge case. Consistency means keeping things in plain old JSON.
Phil
@independentid
www.independentid.com <http://www.independentid.com>
[email protected] <mailto:[email protected]>
On 2013-08-19, at 10:17 AM, George Fletcher <[email protected]
<mailto:[email protected]>> wrote:
+1 "for being able to send unsigned content with JOSE objects" using
a structure that is parallel to signed content
I find symmetric models much less complex than asymmetric ones (maybe
I'm missing the symmetry of the other model).
In practice, most systems are only going to support a subset of the
alg: values anyway and so will have to check the value on every
object to ensure it's one of the ones supported for that library, or
message, etc. Filtering out 'none' is not difficult.
Thanks,
George
On 8/19/13 12:30 PM, Justin Richer 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] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
