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#se > > 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-25 > >> > #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
