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 ACF3C1A6FFB for ; Thu, 29 Jan 2015 20:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 AhOHGcH5q0Ah for ; Thu, 29 Jan 2015 20:43:24 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0672A1A8850 for ; Thu, 29 Jan 2015 20:43:23 -0800 (PST) Received: by mail-oi0-f53.google.com with SMTP id i138so33077626oig.12 for ; Thu, 29 Jan 2015 20:43:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=sxvhOE7ab8aygq3He5VCkoXMk6phM+h/Ns2vH6YDLPI=; b=MZKZkOhGvSXvfm8KqxE5GNRwnmUa/c6YXRgJrzVHBxe1FVVW2jY9eESnvih+CduZVv 7qzEXrI/wm6aFkepp1Yavn3RifkaXAigMrXb5wgH+XsZTk3w6VJQyUxMs37EQU2L/FC0 ALWK2X04EIr4+uRQTRpJsnfUnKYNCb+kFaV+zu5x8vpY4qsIudvmTA3uWI+4SeTZ75k/ g/BezY+R3koKEl3G3xIOHDCeu7oWLMLVgvHVin3w7MnFoZMng877QsuLzqeP2VoIlJ70 7IN/glN2zbXof5H5LJD0pgvUbP4YRthzMZHW3O6tWrqrpj4YxkRSCk2GQwlm3QJ+QhHu 9AGA== MIME-Version: 1.0 X-Received: by 10.202.87.74 with SMTP id l71mr2540253oib.84.1422593003016; Thu, 29 Jan 2015 20:43:23 -0800 (PST) Sender: sakimura@gmail.com Received: by 10.60.171.196 with HTTP; Thu, 29 Jan 2015 20:43:22 -0800 (PST) In-Reply-To: References: Date: Fri, 30 Jan 2015 13:43:22 +0900 X-Google-Sender-Auth: oXMM9ZB2M0-FzZoD6RIyB6lBI3E Message-ID: From: Nat Sakimura To: Brian Campbell Content-Type: multipart/alternative; boundary=001a113b07449ada0b050dd73e1e Archived-At: Cc: oauth , Naveen Agarwal Subject: Re: [OAUTH-WG] PKCE: SHA256(WAT?) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 04:43:25 -0000 --001a113b07449ada0b050dd73e1e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FYI, we are now tracking this issue at: https://bitbucket.org/Nat/oauth-spop/issue/32/clean-up-definitions 2015-01-30 8:15 GMT+09:00 Brian Campbell : > In =C2=A72 [1] we've got "SHA256(STRING) denotes a SHA2 256bit hash [RFC6= 234] > of STRING." > > But, in the little cow town where I come from anyway, you hash bits/octet= s > 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 secon= d > 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 a= nd > 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 =C2=A72 = but > not used anywhere. > > And =C2=A72 also says, "BASE64URL-DECODE(STRING) denotes the base64url de= coding > 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 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a113b07449ada0b050dd73e1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI, we are now tracking this issue at:=C2=A0

2015-01-30 8:15 GMT+09:00 Brian Campbell <bcampbell@pingiden= tity.com>:
In =C2=A72 [1] we've got "SHA256(STRING) deno= tes a SHA2 256bit hash [RFC6234] of STRING."

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

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

I know it's kind of pedantic but I find it k= ind of confusing because the code_verifier uses the url and filename safe a= lphabet, which has me second guessing if SHA256(STRING) actually means a ha= sh 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 exam= ple showing the computation steps on both ends would be helpful?
<= div>
Also "UTF8(STRING)" and "ASCII(STRING)" n= otations are defined in =C2=A72 but not used anywhere.

And =C2=A72 a= lso 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 [R= FC3629] reference, I think, could be removed.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


--001a113b07449ada0b050dd73e1e--