Kathleen - I'm confused by your statement that "Consensus was to remove alg
none" because I am not aware of any such consensus. Rather, the predominant
number of working group participants were in favor of retaining this useful
functionality. That is reflected in Jim's decision to close issue #36 as
"WON'T FIX" in http://www.ietf.org/mail-archive/web/jose/current/msg03586.html.
The functionality was intentionally retained - based on rough consensus of the
working group that it is important.
-- Mike
-----Original Message-----
From: jose [mailto:[email protected]] On Behalf Of Kathleen Moriarty
Sent: Tuesday, April 29, 2014 11:26 AM
To: Jim Schaad
Cc: [email protected]; Vladimir Dzhuvinov
Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms
Thank you, Jim, Vladimir & others. The responses and insight was very helpful
to see how alg "none" is used and that it has been implemented.
I read through the discussion and issue #36. The last message,
http://www.ietf.org/mail-archive/web/jose/current/msg03586.html lets me know
how you got to this point. Consensus was to remove alg none, but it stayed in
the draft because of implementations.
I do agree with the decision in the consensus statement, in favor of removing
alg none as that is cleaner from a design perspective.
Thanks to those who responded on this question with information on
implementation and use as this may get push back during the last call process
via SecDir and the IESG reviews. The additional information provided will be
helpful to explain the current state.
On Tue, Apr 29, 2014 at 2:02 PM, Jim Schaad <[email protected]> wrote:
> Vladimir,
>
> I would be quick to point out that this distinction is true only for
> the compact encoding. It is not true for the JSON encoding where you
> need to figure out from alg field what you are expecting as people can
> give you things which are not so clear cut. (A JSON object with alg
> none and with a signature field for example.)
>
> Jim
>
>
> -----Original Message-----
> From: jose [mailto:[email protected]] On Behalf Of Vladimir
> Dzhuvinov
> Sent: Tuesday, April 29, 2014 7:56 AM
> To: Kathleen Moriarty
> Cc: [email protected]
> Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms
>
> Hello Kathleen,
>
> I found about 80 messages from August 2013 regarding the alg "none"
> discussion, you can view them at
>
> http://www.ietf.org/mail-archive/web/jose/current/thrd3.html
>
> (scroll down to subject "#36...")
>
> The utility of having JOSE-structured objects with protection provided
> at a higher level (e.g. TLS, as used in OpenID Connect) was generally
> understood and agreed. How to write this up and structure it in the
> overall context of the JOSE (and JWT) specs -- there was a lot of discussion
> about that.
>
> Here I would like to add something that may not be immediately
> apparent, but is important from a security perspective -- while "none"
> alg JOSE objects are described in the JWS spec, they have a very
> distinct structure from JWS and JWE objects -- they have only two
> parts -- the JOSE header and the payload. This makes it relatively
> simple and foolproof to distinguish a "none" alg message, without even having
> to inspect the JOSE header.
>
> Implementers can apply this distinction at code level too. The open
> source Nimbus JOSE+JWT library for example uses three separate classes
> to provide type safety -- PlainObject (alg none), JWSObject
> (signature) and JWEObject (encrypted object). So "none" alg objects
> are technically quite distinct from JWS objects, despite being described in
> the same spec.
>
> Regards,
>
> Vladimir
>
>> -------- Original Message --------
>> Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms
>> From: Kathleen Moriarty <[email protected]>
>> Date: Mon, April 28, 2014 3:11 pm
>> To: Justin Richer <[email protected]>
>> Cc: Brian Campbell <[email protected]>, Michael Jones
>> <[email protected]>, "[email protected]" <[email protected]>,
>> "<[email protected]>"
>> <[email protected]>, Vladimir
>> Dzhuvinov <[email protected]>
>>
>>
>> Thanks for the responses on this, it is helpful to see them from a
>> range of folks.
>>
>>
>> On Mon, Apr 28, 2014 at 10:07 AM, Justin Richer <[email protected]> wrote:
>> > +1
>> >
>> > Basically, JOSE defines both crypto processes and container
>> > mechanisms for those processes. "alg:none" lets you use the
>> > container without the crypto in a way that's compatible with using
>> > the same contianer with crypto. Code reuse and parallelism are
>> > awesome. But by explicitly calling out that a thing is unsigned, an
>> > app can decide whether or not it likes unsigned stuff and act
> accordingly.
>> >
>> > -- Justin
>> >
>> >
>> >
>> > On 04/25/2014 06:17 PM, Brian Campbell wrote:
>> >
>> > Plaintext JWSs haven't been free of controversy but the topic has
>> > been discussed many times and the [rough] consensus of the WG is
>> > that
> the "none"
>> > JWS alg is useful. It is in use by the finalized versions of OpenID
>> > Connect, as Vladimir has alluded to. And it has been fairly wildly
>> > deployed in production use.
>> >
>> > The "Plaintext JWS Security Considerations" in section 8.5 of JWA
>> > [1] represents the consensus the WG came to, which keeps the "none"
>> > alg but mandates that implementations "MUST NOT accept such objects
>> > as valid unless the application specifies that it is acceptable for
>> > a
> specific object."
>> >
>> > [1]
>> > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-25#s
>> > e
>> > ction-8.5
>> >
>> > Vladimir
>> > On Fri, Apr 25, 2014 at 2:51 PM, Kathleen Moriarty
>> > <[email protected]> wrote:
>> >>
>> >> Thanks, Vladimir.
>> >>
>> >> Is there consensus in the WG that this is the right thing to do?
>> >> I'm expecting some push-back on this one and want to make sure it
>> >> has consensus behind it. I have heard of a couple of objections
> already.
>> >>
>> >> On Thu, Apr 17, 2014 at 2:10 PM, Vladimir Dzhuvinov
>> >> <[email protected]> wrote:
>> >> >> Thanks, Vladimir.
>> >> >>
>> >> >> How would they be secured then? With the current threat
>> >> >> landscape, it seems odd that we would be putting forth a method
>> >> >> that
> is not secured?
>> >> >> Does this rely on transport for security?
>> >> >
>> >> > Yes, securing the JWS message with TLS for instance, as Mike
>> >> > just pointed out in the his response.
>> >> >
>> >> > JWT-encoded ID tokens in OpenID Connect is one such example, but
>> >> > only when the token is returned from the OAuth 2.0 token
>> >> > endpoint where TLS is mandatory, clients can then register to
>> >> > receive plaintext ID tokens:
>> >> >
>> >> > http://openid.net/specs/openid-connect-core-1_0.html#IDToken
>> >> >
>> >> >
>> >> > There is a section in the JWA spec to instruct developers of the
>> >> > various security considerations regarding use of "none" alg JWS:
>> >> >
>> >> >
>> >> > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-2
>> >> > 5
>> >> > #section-8.5
>> >> >
>> >> >
>> >> > Vladimir
>> >> >
>> >> >
>> >> >
>> >> >> On Thu, Apr 17, 2014 at 12:57 PM, Vladimir Dzhuvinov <
>> >> >> [email protected]> wrote:
>> >> >>
>> >> >> > Hi Kathleen,
>> >> >> >
>> >> >> >
>> >> >> > > Section 3.6 - Can you explain why would this be included?
>> >> >> > > If you are
>> >> >> > not going to sign, I am not sure why one would use JOSE at all.
>> >> >> > >
>> >> >> >
>> >> >> > Perhaps the most popular application of JWS today is to
>> >> >> > construct JSON Web Tokens (JWT), such as the ID tokens in
>> >> >> > OpenID Connect. The JWT spec permits plain tokens that don't
>> >> >> > have a signature and this is enabled by the special case
>> >> >> > "none" alg in JWS.
>> >> >> >
>> >> >> > Plaintext JWTs are explained here:
>> >> >> >
>> >> >> >
>> >> >> > http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-19
>> >> >> > #
>> >> >> > section-6
>> >> >> >
>> >> >> >
>> >> >> > Vladimir
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >> --
>> >> >>
>> >> >> Best regards,
>> >> >> Kathleen
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> Best regards,
>> >> Kathleen
>> >>
>> >> _______________________________________________
>> >> jose mailing list
>> >> [email protected]
>> >> https://www.ietf.org/mailman/listinfo/jose
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > jose mailing list
>> > [email protected]
>> > https://www.ietf.org/mailman/listinfo/jose
>> >
>> >
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>
> _______________________________________________
> jose mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/jose
>
> _______________________________________________
> jose mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/jose
--
Best regards,
Kathleen
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
