Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-09.txt

Brian Campbell <bcampbell@pingidentity.com> Fri, 06 February 2015 00:00 UTC

Return-Path: <bcampbell@pingidentity.com>
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 52A071A700B for <oauth@ietfa.amsl.com>; Thu, 5 Feb 2015 16:00:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.578
X-Spam-Level:
X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 K3jVFldS_S00 for <oauth@ietfa.amsl.com>; Thu, 5 Feb 2015 16:00:33 -0800 (PST)
Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CD31A7011 for <oauth@ietf.org>; Thu, 5 Feb 2015 16:00:32 -0800 (PST)
Received: from mail-ig0-f181.google.com ([209.85.213.181]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKVNQEH6K/vu/eiyvDT2OGg9L+fhC1j9/y@postini.com; Thu, 05 Feb 2015 16:00:32 PST
Received: by mail-ig0-f181.google.com with SMTP id hn18so3173280igb.2 for <oauth@ietf.org>; Thu, 05 Feb 2015 16:00:31 -0800 (PST)
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:from:date :message-id:subject:to:cc:content-type; bh=APtMK150id7LmSeZ5XsS3D9+jl1IjrDZTHc5lIVvUDQ=; b=JsbSNTHag0SK9MF7S/L2gcIqaXxMmFcZMDY4e6ZZDccJbpy+mvmpm/4L5m2t+M3lpB 9CQSnQXNLgyfHxUkfZmUL5LqZHpNtNTLm/k0cufQWkctj/JOV4vYG+XRlpCRZ/0+K7PG nOiUsTkFM4P9Y2Yjql6UCLZYAnwKw+lNjQj6J5rEcPm+a50IAe2Xyeo4g974RF/eSUwQ twLG7XtlA4ZLU8Y/uo9xw/uHiWNQxKcAhEouUrl+7UTswG7YwT1SpvAYv+ReIkSPwJFJ PXAJTNiErfiO/On9/DHUkjVLeflZOic/aCklQC05YJCJ5DjtpNP/oiNhUotK+ydnIcEz 4WwQ==
X-Gm-Message-State: ALoCoQnDCetaxrOADBA0ItmXuUfq+yA9dhHoFf3j5VQi/fdxCyxDtYkDW1BGuysN44Jy2FQVoNO266Gnic352YtkcBSKlnWRHt3N9xuQ3xsdBVHoqPg+tvtpl9Yi9XAW4wWIzRzl8owS
X-Received: by 10.107.156.85 with SMTP id f82mr7924909ioe.45.1423180831351; Thu, 05 Feb 2015 16:00:31 -0800 (PST)
X-Received: by 10.107.156.85 with SMTP id f82mr7924894ioe.45.1423180831210; Thu, 05 Feb 2015 16:00:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.33.75 with HTTP; Thu, 5 Feb 2015 16:00:01 -0800 (PST)
In-Reply-To: <CA+k3eCSEQRR7EjKaYGFrw-Lf+4AQEMNGv-r1TmZkyFsqkACD7w@mail.gmail.com>
References: <20150204234040.19482.87437.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E12851EBA8C3@WSMSG3153V.srv.dir.telstra.com> <97C03A16-4299-44A5-B121-58C6542DF6C1@ve7jtb.com> <CA+k3eCSEQRR7EjKaYGFrw-Lf+4AQEMNGv-r1TmZkyFsqkACD7w@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, 05 Feb 2015 17:00:01 -0700
Message-ID: <CA+k3eCQSYRBrjwKUUZaGqOzwaOJpoFB3Rv=dxve22VGvy8kkNw@mail.gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary="001a1141c3f4e561a9050e601b3d"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/Y7ZMvdBfRv9TzbYH-ZePyygOBHg>
Cc: "oauth@ietf.org" <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
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Feb 2015 00:00:37 -0000

To clarify what I said there: 22-chars (128 bits) seems like way more than
enough for a lower limit when using the "plain" challenge method. When
using the "S256" challenge method, exactly 43 char (256 bits) should
probably always be used.

On Thu, Feb 5, 2015 at 11:09 AM, Brian Campbell <bcampbell@pingidentity.com>
wrote:

> 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 <ve7jtb@ve7jtb.com> wrote:
>
>> Inline
>>
>>
>> > On Feb 4, 2015, at 10:43 PM, Manger, James <
>> James.H.Manger@team.telstra.com> wrote:
>> >
>> >>    Title           : Proof Key for Code Exchange by OAuth Public
>> Clients
>> >>      Filename        : draft-ietf-oauth-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=22-chars is
>> sufficient); and 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.
>> I originally had 43 but it got changed at some point
>>
>> Is there working group feedback on making the lower limit clear in the
>> prose and if so what should it be?  22-chars (128 bits) or 43 char (256
>> bits)?
>>
>>
>> >
>> > 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
>> 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
>> 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) === B64-DECODE(challenge)
>> >  B64-ENCODE(SHA256(verifier)) === 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
>> comparison 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
>> compact 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_challange_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 sooner is
>> better than later.
>>
>> It is that balance between compactness and clear parameter names for
>> developers, 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
>>
>>
>