Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035D51A6F3A for ; Thu, 5 Feb 2015 12:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 JLaHWNUyTS4T for ; Thu, 5 Feb 2015 12:12:11 -0800 (PST) Received: from nm28.bullet.mail.bf1.yahoo.com (nm28.bullet.mail.bf1.yahoo.com [98.139.212.187]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE6431A8AB5 for ; Thu, 5 Feb 2015 12:11:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1423167097; bh=bGlQmVV7aFSiBWesoPsu9+nC8KFR6TySn+SfRiU+Ub0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=qf3lYQxvyktMkWeVecDSKK77/DxASZUEx8J2whdIYIKH6BQ7yq4pUdVkbYLVgh+lgKF+sDZWNhtKyn7Vr9mtYBE2O3Gb3TEmBCwE49qqSQ1rnzP4YGOTuCA4beultFikk3Tl8Qo9lWPjJ8Ks9hIKKtTrqBrvLiMjZKiFLIS3tskrP9C1ICjnaATJ4mQuTzZ0oF2QMKZzwqGFZhS1VIsl7hJK4hSm1A1CAJjU2n4nuVq/hNc/BUoEQS12cSqwMY1Cs6N4R4FZUoOxU3pE2YKwG+CjZLNeyyS/ckDSf+heT0fJH/oyB0av3ZoUACURxqcGEN1LtC8dyo1F9OeKIje6JQ== Received: from [98.139.212.151] by nm28.bullet.mail.bf1.yahoo.com with NNFMP; 05 Feb 2015 20:11:37 -0000 Received: from [98.139.212.249] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 05 Feb 2015 20:11:37 -0000 Received: from [127.0.0.1] by omp1058.mail.bf1.yahoo.com with NNFMP; 05 Feb 2015 20:11:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 55224.69364.bm@omp1058.mail.bf1.yahoo.com X-YMail-OSG: 0Xppt1YVM1lzYk470uTrMmcRTQ9t4wTXh2T4Z1YlG2Iam9KtlAfzMRnJwesyPI4 3687g8yJ9dAb2WEEgrqfPwBaM_oWfwpPiqedq5e_tSLg7GrHTOwFdI6kM26pPGo.7N1QS3PDIDBn KFElahNzItYTjSn6QCbk92QAicn5b9UBzq1dFPmJx.OTXYO5TmmNbUhCZMzK2pBtHVHnMwdzs4DZ fmfyyvvVrK19P2PtJXj.yaIUORc9yil2ib1RogxTvuCdWBf1YPUsbjSempGtyeIBS.V2t93yBx5V JeBiGMmCWbbPnFyPviC6Ym_OLUX7psM7O0x7dT4CmYMdNoHt26HhKlGfsRyFKymRmPBKbdQuiyoE RQMor6qQN8gYB8wwaOtBlyLlmsHRNcNB9BflebI2BsJohc.Cvdmhcp.76SlwvWBiXgF7sSLlYeZe PsXy8XthXrLI7rbNoGSzU6293V5Cy5MuZkwNSRk1cbCE3sxqYOnU7JDW5ZRgX0oeBPZeWWhhWkIF U1m37q5ZbqWL.7g-- Received: by 76.13.27.54; Thu, 05 Feb 2015 20:11:36 +0000 Date: Thu, 5 Feb 2015 20:11:36 +0000 (UTC) From: Bill Mills To: Brian Campbell , John Bradley Message-ID: <539792956.415454.1423167096100.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_415453_1585801587.1423167096094" Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-09.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 20:12:13 -0000 ------=_Part_415453_1585801587.1423167096094 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Is there a compelling reason to make that length fixed? =C2=A0 =20 On Thursday, February 5, 2015 10:10 AM, Brian Campbell wrote: =20 22-chars (128 bits) as a lower limit seems just fine for this case. "ccm" works for me but I don't feel strongly about it either way. On Thu, Feb 5, 2015 at 9:49 AM, John Bradley wrote: Inline > On Feb 4, 2015, at 10:43 PM, Manger, James wrote: > >>=C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Proof Key f= or Code Exchange by OAuth Public Clients >>=C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-oau= th-spop-09.txt >> https://tools.ietf.org/html/draft-ietf-oauth-spop-09 > > > Some nits on this draft: > > 1. 42 chars. > The lower limit of 42 chars for code_verifier: is not mentioned in prose = (just the upper limit); is too high (128-bits=3D22-chars is sufficient); an= d doesn't correspond to 256-bits (BASE64URL-ENCODE(32 bytes) gives 43 chars= , not 42). In my editors draft I fixed the 43 octet base64url encoding of 32bytes.=C2= =A0 I originally had 43 but it got changed at some point Is there working group feedback on making the lower limit clear in the pros= e and if so what should it be?=C2=A0 22-chars (128 bits) or 43 char (256 bi= ts)? > > 2. > Quotes around "code_verifier" and "code_challenge" in prose are okay, tho= ugh not really necessary as the underscore is enough to distinguish them as= technical labels. Quotes around these terms in formula is bad as it looks = like the formula applies to the 13 or 14 chars of the label. The quoting is= also used inconsistently. > Suggestion: remove all quotes around "code_verifier" and "code_challenge"= in prose and formula. > For example, change ASCII("code_verifier") to ASCII(code_verifier). > I am going to leave this for a later formatting cleanup at the moment, I ne= ed to find a good style compromise that works with rfcmarkup. > 3. > Two ways to check code_verifier are given in appendix B, whereas only one= of these is mentioned in section 4.6. >=C2=A0 SHA256(verifier) =3D=3D=3D B64-DECODE(challenge) >=C2=A0 B64-ENCODE(SHA256(verifier)) =3D=3D=3D challenge > > I suggest only mentioning the 2nd (change 4.6 to use the 2nd, and drop th= e 1st from appendix B). It is simpler to mention only one. It also means ba= se64url-decoding is never done, and doesn't need to be mentioned in the spe= c. > Yes when I added the example I realized that the normative text was the mor= e complicated way to do the comparison. I will go back and refactor the main text to talk about the simpler compari= son and drop the base64url-decode references. > > 4. > Expand "MTI" to "mandatory to implement". Done in editors draft. > > P.S. Suggesting code challenge method names not exceed 8 chars to be comp= act is a bit perverse given the field holding these values has the long nam= e "code_challenge_method" ;) =C2=A0 On the topic of the parameter=C2=A0 name=C2=A0 "code_challange_metho= d",=C2=A0 James has a point in that it is a bit long. We could shorten it to "ccm".=C2=A0 =C2=A0If we want to change the name soo= ner is better than later. It is that balance between compactness and clear parameter names for develo= pers, that we keep running into. I don't know that encouraging longer parameter values is the best direction= . Feedback please John B. > > -- > James Manger > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_Part_415453_1585801587.1423167096094 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is there a compelling reason to make t= hat length fixed?  


=
On Thursday, Fe= bruary 5, 2015 10:10 AM, Brian Campbell <bcampbell@pingidentity.com> = wrote:


22-chars (128 bits) as a lowe= r limit seems just fine for this case.

"ccm" works for me but I don't feel strongly about it either way.


On Thu, Feb 5, 2015 at 9:49 AM, John Bradley <<= a rel=3D"nofollow" shape=3D"rect" ymailto=3D"mailto:ve7jtb@ve7jtb.com" targ= et=3D"_blank" href=3D"mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com> wrote:
Inline


> On Feb 4, 2015, at 10:43 PM, Manger, James <James.H.Manger@team.t= elstra.com> wrote:
>
>>    Title           : Proof= Key for Code Exchange by OAuth Public Clients
>>      Filename        : draft-ie= tf-oauth-spop-09.txt
>> https://tools.ietf.org/htm= l/draft-ietf-oauth-spop-09
>
>
> Some nits on this draft:
>
> 1. 42 chars.
> The lower limit of 42 chars for code_verifier: is not mentioned in pro= se (just the upper limit); is too high (128-bits=3D22-chars is sufficient);= and doesn't correspond to 256-bits (BASE64URL-ENCODE(32 bytes) gives 43 ch= ars, not 42).

In my editors draft I fixed the 43 octet base64url encoding of 32byt= es.  I originally had 43 but it got changed at some point

Is there working group feedback on making the lower limit clear in the pros= e and if so what should it be?  22-chars (128 bits) or 43 char (256 bi= ts)?


>
> 2.
> Quotes around "code_verifier" and "code_challenge" in prose are okay, = though not really necessary as the underscore is enough to distinguish them= as technical labels. Quotes around these terms in formula is bad as it loo= ks like the formula applies to the 13 or 14 chars of the label. The quoting= is also used inconsistently.
> Suggestion: remove all quotes around "code_verifier" and "code_challen= ge" in prose and formula.
> For example, change ASCII("code_verifier") to ASCII(code_verifier). >

I am going to leave this for a later formatting cleanup at the momen= t, I need to find a good style compromise that works with rfcmarkup.

> 3.
> Two ways to check code_verifier are given in appendix B, whereas only = one of these is mentioned in section 4.6.
>  SHA256(verifier) =3D=3D=3D B64-DECODE(challenge)
>  B64-ENCODE(SHA256(verifier)) =3D=3D=3D challenge
>
> I suggest only mentioning the 2nd (change 4.6 to use the 2nd, and drop= the 1st from appendix B). It is simpler to mention only one. It also means= base64url-decoding is never done, and doesn't need to be mentioned in the = spec.
>
Yes when I added the example I realized that the normative text was = the more complicated way to do the comparison.

I will go back and refactor the main text to talk about the simpler compari= son and drop the base64url-decode references.
>
> 4.
> Expand "MTI" to "mandatory to implement".

Done in editors draft.
>
> P.S. Suggesting code challenge method names not exceed 8 chars to be c= ompact is a bit perverse given the field holding these values has the long = name "code_challenge_method" ;)

  On the topic of the parameter  name  "code_challang= e_method",  James has a point in that it is a bit long.

We could shorten it to "ccm".   If we want to change the name soo= ner is better than later.

It is that balance between compactness and clear parameter names for develo= pers, that we keep running into.

I don't know that encouraging longer parameter values is the best direction= .

Feedback please

John B.
>
> --
> James Manger
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/o= auth


____________________________________________= ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= /a>


=



<= /div>
------=_Part_415453_1585801587.1423167096094--