Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A760E1A0310 for ; Wed, 17 Sep 2014 04:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBBf5bLpBRl5 for ; Wed, 17 Sep 2014 04:40:07 -0700 (PDT) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F26E01A00FA for ; Wed, 17 Sep 2014 04:40:06 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id u57so1270375wes.8 for ; Wed, 17 Sep 2014 04:40:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nXns91o69u7OIojyqugWnOQpJEqDh9CG7mMTbHGSw0Q=; b=XMhV9I4cDXG8JaZ21Z9Tw73GXMzZdJML55KXLf0oGtvBmx6hiABSgS0/flpKOdxKAA 2j9MoW+enBOuthM7AlTv4brL9FXIYx1oCo3+zBqc7ng3Oa0/g7kJJGzYdtvdPXqbhyRV xyvFrJT9aa1GWKTxWAHaaIt5u2e8+zLpCG9xoB8vHkGb49BbrNLsEhTy5U9K+FnXi3pN vE2iRZ4NYnSAXZTF5HYNe34wTfILlnX4JLR+970q5oHRJO7FX9LfvDmXujjIuFyg0FZw +UyFDe4NLeoPEXV3+OnAOo7px/ts4mPOvqvvU5E9bOe+EfRFinHnOHScBGwNjo2Y8XK0 KqrQ== X-Gm-Message-State: ALoCoQlZpOWPvVr2HKst6l7r9De9Bb914f91k+0fJj/MPIlhEwN2/vCsS5CKNxAx73eykaqs/sTj MIME-Version: 1.0 X-Received: by 10.194.24.169 with SMTP id v9mr2699538wjf.114.1410954005479; Wed, 17 Sep 2014 04:40:05 -0700 (PDT) Received: by 10.194.62.39 with HTTP; Wed, 17 Sep 2014 04:40:05 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Sep 2014 07:40:05 -0400 Message-ID: From: Warren Kumari To: Richard Barnes Content-Type: multipart/alternative; boundary=047d7b45101a4a9ea60503415491 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/wPNgzZaeGxfks8UQqqfA2vTKCwI Cc: "secdir@ietf.org" , "draft-ietf-oauth-json-web-token.all@tools.ietf.org" , Mike Jones , "jose@ietf.org" , Brian Campbell , "oauth@ietf.org" Subject: Re: [secdir] alternative term to "plaintext" for the "none" alg (was Re: [OAUTH-WG] Review of: draft-ietf-oauth-json-web-token) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 11:40:09 -0000 --047d7b45101a4a9ea60503415491 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, September 16, 2014, Richard Barnes wrote: > I will re-iterate here my strong preference that an "unsecured" or > "plaintext" JWS object be syntactically distinct from a real JWS object. > E.g. by having two dot-separated components instead of three. > So, *I* was just grumping about the term used in the draft, but yes, these should (IMO, etc) be different. I'm also still uncomfortable about the "you can have the same information in the "secured" and "unsecured" section, but the secured one shold be trusted more bit. This seems like it will end in fail. (Apologies if this was already discussed and I missed it, and for rushed tone of mail, traveling...) W > Beyond that, seems like just shuffling deck chairs. > > On Mon, Sep 8, 2014 at 12:10 PM, Brian Campbell < > bcampbell@pingidentity.com > > wrote: > >> cc'ing JOSE on a minor JWT review comment that might impact JWS/JWA. >> >> I agree that "plaintext=E2=80=9D is not the most intuitive wording choic= e and >> that "unsecured" might better convey what's going on with the "none" JWS >> algorithm. >> >> Mike mentioned that, if this change is made in JWT, there are parallel >> changes in JWS. But note that there are also such changes in JWA (more t= han >> in JWS actually). >> >> On Fri, Sep 5, 2014 at 6:28 PM, Mike Jones > > wrote: >> >>> -----Original Message----- >>> From: Warren Kumari [mailto:warren@kumari.net >>> ] >>> Sent: Monday, September 01, 2014 3:40 PM >>> To: secdir@ietf.org ; >>> draft-ietf-oauth-json-web-token.all@tools.ietf.org >>> >>> Subject: Review of: draft-ietf-oauth-json-web-token >>> >>> I'm a little confused by something in the Terminology section (Section >>> 2): >>> >>> Plaintext JWT >>> >>> A JWT whose Claims are not integrity protected or encrypted. >>> >>> The term plaintext to me means something like "is readable without >>> decrypting / much decoding" (something like, if you cat the file to a >>> terminal, you will see the information). Integrity protecting a string >>> doesn't make it not easily readable. If this document / JOSE uses >>> "plaintext" differently (and a quick skim didn't find anything about >>> >>> this) it might be good to clarify. Section 6 *does* discuss plaintext >>> JWTs, but doesn't really clarify the (IMO) unusual meaning of the term >>> "plaintext" here. >>> >>> >>> >>> I=E2=80=99ve discussed this with the other document editors and we agre= e with >>> you that =E2=80=9Cplaintext=E2=80=9D is not the most intuitive wording = choice in this >>> context. Possible alternative terms are =E2=80=9CUnsecured JWT=E2=80= =9D or =E2=80=9CUnsigned >>> JWT=E2=80=9D. I think that =E2=80=9CUnsecured JWT=E2=80=9D is probably= the preferred term, since >>> JWTs that are JWEs are also unsigned, but they are secured. Working gr= oup >>> =E2=80=93 are you OK with this possible terminology change? (Note that= the >>> parallel change =E2=80=9CPlaintext JWS=E2=80=9D -> =E2=80=9CUnsecured J= WS=E2=80=9D would also be made in >>> the JWS spec.) >>> >>> >>> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> >> > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --047d7b45101a4a9ea60503415491 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tuesday, September 16, 2014, Richard Barnes <rlb@ipv.sx> w= rote:
I will re-ite= rate here my strong preference that an "unsecured" or "plain= text" JWS object be syntactically distinct from a real JWS object.=C2= =A0 E.g. by having two dot-separated components instead of three.

So, *I* was just grumping about the term used= in the draft, but yes, these should (IMO, etc) be different.

I'm also still=C2=A0uncomfortable about the "you can have th= e same information in the "secured" and "unsecured" sec= tion, but the secured one shold be trusted more bit. This seems like it wil= l end in fail. (Apologies if this was already discussed and I missed it, an= d for rushed tone of mail, traveling...)

W

=C2=A0
Beyond that, seems like just shuffling deck chairs.

On Mon, Se= p 8, 2014 at 12:10 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
cc'ing JOSE on a minor JWT revi= ew comment that might impact JWS/JWA.

I agree that "plain= text=E2=80=9D is not the most intuitive wording choice and that "unsec= ured" might better convey what's going on with the "none"= ; JWS algorithm.

Mike mentioned that, if this change is = made in JWT, there are parallel changes in JWS. But note that there are als= o such changes in JWA (more than in JWS actually).

On Fri, Sep 5, 2014 at= 6:28 PM, Mike Jones <M= ichael.Jones@microsoft.com> wrote:

-----Original Message-----
From: Warren Kumari [mailto:warren@kumari.net] Sent: Monday, September 01, 2014 3:40 PM
To: secdir@ietf.org; draft-ietf-oauth-json-web-token.all@tools.ietf.org
Subject: Review of: draft-ietf-oauth-json-web-token

I'm a little confused by something in the Terminology section (Secti= on 2):

Plaintext JWT

A JWT whose Claims are not integrity protected or encrypted.

The term plaintext to me means something like "is readable without = decrypting / much decoding" (something like, if you cat the file to a = terminal, you will see the information). Integrity protecting a string does= n't make it not easily readable. If this document / JOSE uses "plaintext" differently (= and a quick skim didn't find anything about

this) it might be good to clarify. Section 6 *does* discuss plaintext JW= Ts, but doesn't really clarify the (IMO) unusual meaning of the term &q= uot;plaintext" here.

=C2=A0

I=E2=80=99ve discussed this with th= e other document editors and we agree with you that =E2=80=9Cplaintext=E2= =80=9D is not the most intuitive wording choice in this context.=C2=A0 Poss= ible alternative terms are =E2=80=9CUnsecured JWT=E2=80=9D or =E2=80=9CUnsi= gned JWT=E2=80=9D.=C2=A0 I think that =E2=80=9CUnsecured JWT=E2=80=9D is probab= ly the preferred term, since JWTs that are JWEs are also unsigned, but they= are secured.=C2=A0 Working group =E2=80=93 are you OK with this possible t= erminology change?=C2=A0 (Note that the parallel change =E2=80=9CPlaintext = JWS=E2=80=9D -> =E2=80=9CUnsecured JWS=E2=80=9D would also be made in the JWS spec.)

=C2=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose




--
I don't think the execution is releva= nt when it was obviously a bad idea in the first place.
This is like put= ting rabid weasels in your pants, and later expressing regret at having cho= sen those particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0= ---maf
--047d7b45101a4a9ea60503415491--