[OAUTH-WG] PKCE: SHA256(WAT?)

Brian Campbell <bcampbell@pingidentity.com> Thu, 29 January 2015 23:16 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 9306F1A802F for <oauth@ietfa.amsl.com>; Thu, 29 Jan 2015 15:16:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.072
X-Spam-Level:
X-Spam-Status: No, score=-2.072 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, SUBJ_ALL_CAPS=1.506] 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 SduOQAe1VAku for <oauth@ietfa.amsl.com>; Thu, 29 Jan 2015 15:16:33 -0800 (PST)
Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37FB41A1E0B for <oauth@ietf.org>; Thu, 29 Jan 2015 15:16:33 -0800 (PST)
Received: from mail-ie0-f176.google.com ([209.85.223.176]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKVMq/SzRoatTbKkKfQdEJAp7sqH7rqbnm@postini.com; Thu, 29 Jan 2015 15:16:33 PST
Received: by mail-ie0-f176.google.com with SMTP id at20so1078559iec.7 for <oauth@ietf.org>; Thu, 29 Jan 2015 15:16:27 -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:from:date:message-id:subject:to:cc :content-type; bh=urcUkMUM59Ccw84ioBgv2sEKO9yJAA3x+JMMRT9rpU4=; b=RRO8PTz5nNf6F0PzMv5ia2e4U6E/mAXm/I7pNwfqwLabPjAOInBD9KhWSzeejzGlNV x/z7iMOr4GX11R6lDO8XGfTv2grBDQKQq+QLncyJHtKZOzqO3hbE8VakDBUrKcIhgpLB WmVX4Bf1s+9iCV33d9Ls+8aTY/ZUP5KBcILunesyrU088Uqf9s1A9h+BwaLOPpc+aUVG jPRlbgK21vUUGNGZyGkzvHmnPgrbAFlLu2M8Ms8NxNMkCJWjcqS40O65H1n+bM3kT0AH sPU1A76xePTbGSz6C/63fJPnPFLeI5lzIa/HGl0yIxWNy4zBGhtY7G+zaBUfc9Z8dsKV 8YkA==
X-Gm-Message-State: ALoCoQlsXtGJaEH2D58604zf+LLFMV4awxAVAUJb/CB5x9aZYDmm1eKILMx8nNO6t/7hNzVAV0q4v0d7PsvGXVBiPleNVhRfKai2QPwkhGgDmJZZWcIhytla5TXDmdAc5dpMZYYSNeCz
X-Received: by 10.50.108.108 with SMTP id hj12mr3950033igb.47.1422573387186; Thu, 29 Jan 2015 15:16:27 -0800 (PST)
X-Received: by 10.50.108.108 with SMTP id hj12mr3950025igb.47.1422573387102; Thu, 29 Jan 2015 15:16:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.33.75 with HTTP; Thu, 29 Jan 2015 15:15:56 -0800 (PST)
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, 29 Jan 2015 16:15:56 -0700
Message-ID: <CA+k3eCQHZJYJ3mMfdGTdO=S3VVQdU+qhjVz+QsEeobJokNSHEA@mail.gmail.com>
To: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary=089e0149392a67cff8050dd2adea
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/1sJkLkmtwz69b005dDCTorsxcSI>
Cc: Nat Sakimura <nat@sakimura.org>, Naveen Agarwal <naa@google.com>
Subject: [OAUTH-WG] PKCE: SHA256(WAT?)
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: Thu, 29 Jan 2015 23:16:35 -0000

In §2 [1] we've got "SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of
STRING."

But, in the little cow town where I come from anyway, you hash bits/octets
not character strings (BTW, "STRING" isn't defined anywhere but it's kind
of implied that it's a string of characters).

Should it say something more like "SHA256(STRING) denotes a SHA2 256bit
hash [RFC6234] of the octets of the ASCII [RFC0020] representation of
STRING."?

I know it's kind of pedantic but I find it kind of confusing because the
code_verifier uses the url and filename safe alphabet, which has me second
guessing if SHA256(STRING) actually means a hash of the octet produced by
base64url decoding the string.

Maybe it's just me but, when reading the text, I find the transform process
to be much more confusing than I think it needs to be. Removing and
clarifying some things will help. I hate to suggest this but maybe an
example showing the computation steps on both ends would be helpful?

Also "UTF8(STRING)" and "ASCII(STRING)" notations are defined in §2 but not
used anywhere.

And §2 also says, "BASE64URL-DECODE(STRING) denotes the base64url decoding
of STRING, per Section 3, producing a UTF-8 sequence of octets." But what
is a UTF-8 sequence of octets? Isn't it just a sequence octets? The
[RFC3629] reference, I think, could be removed.

[1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-2