Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-spop-14: (with COMMENT)

Nat Sakimura <sakimura@gmail.com> Tue, 07 July 2015 16:10 UTC

Return-Path: <sakimura@gmail.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 0831B1A8981; Tue, 7 Jul 2015 09:10:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 jHSEf6BzHjft; Tue, 7 Jul 2015 09:10:04 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B5C71A8F46; Tue, 7 Jul 2015 09:09:59 -0700 (PDT)
Received: by oiyy130 with SMTP id y130so145265367oiy.0; Tue, 07 Jul 2015 09:09:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CNI8DnGsvklNK1PvsCV6XGfUPCFsb9q1rBPxn2pMvv0=; b=OgCuWeph5TVzxlh5GNJsHzR2O/XlF4BwA8ZI9Snjd0TKzY+eXYsvaFNaLlcKOT5DaZ vxWKQ6ZigaU9AQ0cQmpMSm9LW1zz5oz0Wf8SpinzeBxWeivQY3IXSDqqoWTep6jeb3XN jh9ExhD8MQlzOD1EXYguBjEK6tvG+qPjAMhZqc8i7Q95z3zCvbQIQjDz8w3G+ZNYgJxY J8GHUpL2AGyiCdb7g9QZR9IwcODJiGdDwk/ohkri7eGNcBX1sYUf2qNUUCBMMTe/8FGJ 2lpV26m1KTY2oPUXoYk/hL7IlAqsMPuYn/sw5TqO3oqj9saV5SHyfodinCCuL/t1bXkg GWZA==
MIME-Version: 1.0
X-Received: by 10.202.64.195 with SMTP id n186mr4734882oia.53.1436285398562; Tue, 07 Jul 2015 09:09:58 -0700 (PDT)
Received: by 10.182.96.66 with HTTP; Tue, 7 Jul 2015 09:09:58 -0700 (PDT)
In-Reply-To: <20150707024902.24716.2952.idtracker@ietfa.amsl.com>
References: <20150707024902.24716.2952.idtracker@ietfa.amsl.com>
Date: Wed, 8 Jul 2015 01:09:58 +0900
Message-ID: <CABzCy2AW474zv7EU0EZ3UpQP74S2CRmBZuzLs8FG_=Ey7E_GXw@mail.gmail.com>
From: Nat Sakimura <sakimura@gmail.com>
To: Barry Leiba <barryleiba@computer.org>
Content-Type: multipart/alternative; boundary=001a113dd1e6fa3cba051a4b404a
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/6_wBdR2wWPpBqMOVoJSo2OgGjyg>
Cc: draft-ietf-oauth-spop@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-spop.shepherd@ietf.org, The IESG <iesg@ietf.org>, oauth <oauth@ietf.org>, draft-ietf-oauth-spop.ad@ietf.org
Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-spop-14: (with COMMENT)
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 07 Jul 2015 16:10:07 -0000

Thanks Barry,


These are the issues that I wanted to discuss with John before making
change.

-- Section 6.2 -- John has partly addressed your IANA comment already. I
needed
to check if there was any reason for just doing partly.

-- Section 7.2 -- is probably just my oversight. I will deal with it.

-- Section 2 -- : I agree with you and I wanted to confirm it with John and
other people to commit the change.

Cheers,

Nat

2015-07-07 11:49 GMT+09:00 Barry Leiba <barryleiba@computer.org>;:

> Barry Leiba has entered the following ballot position for
> draft-ietf-oauth-spop-14: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Version -14 resolves my DISCUSS (and also some of my non-blocking
> comments).  Thanks very much for considering these and working with me on
> them!
>
>   =========================================
> My comment about the IANA Considerations remains.  While it's
> non-blocking, I still hope you will accept the change I suggest:
>
> -- Section 6.2 --
> I have the same comment here as in the other OAuth document: please shift
> the focus away from telling IANA how to handle tracking of the expert
> review, and make the mailing list something that the designated expert(s)
> keep track of.  Also, please give more instructions to the DEs about what
> they should consider when they're evaluating a request (for example,
> should they approve all requests, or are there criteria they should
> apply?).
>
> For the first, here's a text change that I suggest we move toward for
> this sort of thing:
>
> OLD
> <most of Section 6.2>
>
> NEW
>    Additional code_challenge_method types for use with the authorization
>    endpoint are registered using the Specification Required policy
>    [RFC5226], which includes review of the request by one or more
>    Designated Experts.  The DEs will ensure there is at least a two-week
>    review of the request on the oauth-ext-review@ietf.org mailing list,
>    and that any discussion on that list converges before they respond to
>    the request.  To allow for the allocation of values prior to
>    publication, the Designated Expert(s) may approve registration once
>    they are satisfied that an acceptable specification will be
> published.
>
>    Discussion on the oauth-ext-review@ietf.org mailing list should use
>    an appropriate subject, such as "Request for PKCE
>    code_challenge_method: example").
>
>    The Designated Expert(s) should consider the discussion on the
>    mailing list, as well as <<these other things>> when evaluating
>    registration requests.  Denials should include an explanation
>    and, if applicable, suggestions as to how to make the request
>    successful.
> END
>
>   =========================================
> -- Section 7.2 --
> I find the first first paragraph confusingly worded, and after discussion
> with the author I suggest this:
>
> NEW
> Clients MUST NOT downgrade to "plain" after trying the S256 method.
> Because servers are required to support S256, an error when S256 is
> presented can only mean that the server does not support PKCE at all.
> Otherwise, such an error could be indicative of a MITM attacker trying
> a downgrade attack.
> END
>
>   =========================================
> Finally, there is this comment, which is not a big deal and you should
> proceed as you think best:
>
> -- Section 2 --
> There is no real distinction between STRING and ASCII(STRING), because
> STRING is already defined to be ASCII.  Using "ASCII(xxx)" only adds
> clutter, and a suggest removing it.
>
> So, for example, that would result in changes such as this:
>
> OLD
> BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) == code_challenge
> NEW
> BASE64URL-ENCODE(SHA256(code_verifier)) == code_challenge
> END
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en