Actually, it is true for the JSON encoding. The "alg":"none" case is the only
one in which "signature":"" may occur in the JSON serialization - just like it
is the only case in which an empty third segment may occur in the compact
serialization. Looking for "signature":"" is just as easy as looking for the
empty third segment.
-- Mike
-----Original Message-----
From: jose [mailto:[email protected]] On Behalf Of Jim Schaad
Sent: Tuesday, April 29, 2014 11:03 AM
To: 'Vladimir Dzhuvinov'; 'Kathleen Moriarty'
Cc: [email protected]
Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms
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
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
