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 349451A3B9D for ; Fri, 30 Jan 2015 12:16:19 -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 ABLs903F6W43 for ; Fri, 30 Jan 2015 12:16:15 -0800 (PST) Received: from na3sys009aog118.obsmtp.com (na3sys009aog118.obsmtp.com [74.125.149.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3D0B1A1EEF for ; Fri, 30 Jan 2015 12:16:13 -0800 (PST) Received: from mail-ie0-f177.google.com ([209.85.223.177]) (using TLSv1) by na3sys009aob118.postini.com ([74.125.148.12]) with SMTP ID DSNKVMvmjbTS6/PYoZiiCYo29Jbd2lSUXXpg@postini.com; Fri, 30 Jan 2015 12:16:13 PST Received: by mail-ie0-f177.google.com with SMTP id vy18so5900451iec.8 for ; Fri, 30 Jan 2015 12:16:12 -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=p6obOiPy6xFbMrjtorrsS33C1QmgQYIWZh1nigz0Aog=; b=J2PjPG6WEGSSCcpOnpfy7Eut8a2rtgiRR64v37M4jujlsf+JZ6eqTm5ArTg4V38X/I 7wmG7PHmbwGR2Oz3zH/XtG4Hz/YKgoL/o/SK1ekLlnnnXiuzga2SMsWjMUW9N04nBx1Q FBxcLec6Oknl793a7rTVwx5BT3cQvzm2d107U40IaA1b/cjhghUzwH6HRO0yeoGVjhvB 3utASmF5lloF6HM6yQ177nI4iWdzGg7TrZb1/z3sDDDRUqpws5/vKrDUsX7QtO2ZlUze 20fGcSPBu81H3y0KyBTdd65FoZT2vtMT4nI/p0EZqYT1MS4mD93I2LnupU6/JB25auX7 8GIA== X-Gm-Message-State: ALoCoQkihzhnIM533eczHp5SILRIM5TzbtEvvKz0oReYK2IBlHCdXbH+vUibyzd6kcSgPevzWl06mo4iNfRTWD9NxSEKdgdS8NOATFCLiHwUgmBDwkwNP518wjUyhyM/fRmZh7tU3kJd X-Received: by 10.42.200.82 with SMTP id ev18mr8062565icb.44.1422648972878; Fri, 30 Jan 2015 12:16:12 -0800 (PST) X-Received: by 10.42.200.82 with SMTP id ev18mr8062546icb.44.1422648972728; Fri, 30 Jan 2015 12:16:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.33.75 with HTTP; Fri, 30 Jan 2015 12:15:42 -0800 (PST) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943A2201928@TK5EX14MBXC291.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943A2201928@TK5EX14MBXC291.redmond.corp.microsoft.com> From: Brian Campbell Date: Fri, 30 Jan 2015 13:15:42 -0700 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=20cf30223d83a8f18d050de44685 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 20:16:19 -0000 --20cf30223d83a8f18d050de44685 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with Mike here. Though PKCE only needs the ASCII(STRING) one. On Fri, Jan 30, 2015 at 12:38 PM, Mike Jones wrote: > > http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-= 1.1 > uses this notation: > > > > UTF8(STRING) denotes the octets of the UTF-8 [RFC3629 > ] representation > > of STRING, where STRING is a sequence of zero or more Unicode > > [UNICODE > ] > characters. > > > > ASCII(STRING) denotes the octets of the ASCII [RFC20 > ] representation > > of STRING, where STRING is a sequence of zero or more ASCII > > characters. > > > > This is unambiguous and has already been vetted by the IESG and SecDir, s= o > I would use exactly this wording. > > > > OCTETS(STRING) is ambiguous, since for the same string there are many > possible representations as octets, including ASCII, UTF-8, UTF-16, UTF-3= 2, > and EBCDIC. > > > > -- Mike > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John Bradley > *Sent:* Friday, January 30, 2015 11:33 AM > *To:* Brian Campbell > *Cc:* oauth; Naveen Agarwal > *Subject:* Re: [OAUTH-WG] PKCE: SHA256(WAT?) > > > > Have a look at the latest version I added OCTETS(STRING) to show the > conversion. ASCII(STRING) seemed more confusing by drawing character > encoding back in. > > > > I was tempted to call it a octet array without the terminating NULL of > STRING but didn=E2=80=99t want to introduce array. > > > > Let me know what you think. > > > > On Jan 30, 2015, at 1:56 PM, Brian Campbell > wrote: > > > > But, while it may be clear to you, what I'm saying here is that it's not > clear to a reader/implementer. > > Somehow the conversion from a character string to an octet string needs t= o > be clearly and unambiguously stated. It doesn't have to be the text I > suggested but it's not sufficient as it is now. > > Something like this might work, if you don't want to touch the parts in > 4.2 and 4.6: "SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of the > octets of the ASCII [RFC0020] representation of STRING." > > An "octet sequence using the url and filename safe Alphabet [...], with > length less than 128 characters." is ambiguous. Octets and characters are > intermixed with no mention of encoding. But they're not interchangeable. > > > > > > On Fri, Jan 30, 2015 at 7:15 AM, Nat Sakimura wrote: > > I do not think we need ASCII(). It is quite clear without it, I suppose. > > > > In 4.1, I would rather do like: > > > > code_verifier =3D high entropy cryptographic random > octet sequence using the url and filename safe Alphabet [A-Z] / [a-z] > / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length > less than 128 characters. > > > > Nat > > > > 2015-01-30 22:51 GMT+09:00 Brian Campbell : > > That's definitely an improvement (to me anyway). > > Checking that the rest of the document uses those notations appropriately= , > I think, yields a few other changes. And probably begs for the > "ASCII(STRING) denotes the octets of the ASCII representation of STRING" > notation/function, or something like it, to be put back in. Those changes > might look like the following: > > In 4.1.: > > OLD: > code_verifier =3D high entropy cryptographic random ASCII [RFC0020] > octet sequence using the url and filename safe Alphabet [A-Z] / [a-z] > / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length > less than 128 characters. > > NEW (maybe): > code_verifier =3D high entropy cryptographically strong random STRING > using the url and filename safe Alphabet [A-Z] / [a-z] > / [0-9] / "-" / "_" from Sec 5 of RFC 4648 [RFC4648], with length > less than 128 characters. > > > In 4.2.: > > OLD: > S256 "code_challenge" =3D BASE64URL(SHA256("code_verifier")) > > NEW (maybe): > S256 "code_challenge" =3D BASE64URL(SHA256(ASCII("code_verifier"))) > > In 4.6.: > > OLD: > SHA256("code_verifier" ) =3D=3D BASE64URL-DECODE("code_challenge"). > > NEW (maybe): > SHA256(ASCII("code_verifier")) =3D=3D BASE64URL-DECODE("code_challenge= "). > > > > > > On Thu, Jan 29, 2015 at 8:37 PM, Nat Sakimura (=3Dnat) > wrote: > > I take your point, Brian. > > > > In our most recent manuscript, STRING is defined inside ASCII(STRING) as > > > > STRING is a sequence of zero or more ASCII characters > > > > but it is kind of circular, and we do not seem to use ASCII(). > > > > What about re-writing the section like below? > > > > STRING denotes a sequence of zero or more ASCII [RFC0020] > characters. > > OCTETS denotes a sequence of zero or more octets. > > BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per Section 3 > producing a > ASCII[RFC0020] > STRING. > > BASE64URL-DECODE(STRING) denotes the base64url decoding of STRING, per Se= ction > 3 , producing a > sequence of octets. > > SHA256(OCTETS) denotes a SHA2 256bit hash [RFC6234] > of OCTETS. > > > > > > > > > > > > On Jan 30, 2015, at 08:15, Brian Campbell > wrote: > > > > 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 > > > > Nat Sakimura > > nat@sakimura.org > > > > > > > > > > > > > > > > -- > > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > > --20cf30223d83a8f18d050de44685 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with Mike here. Though PKCE only needs the ASCII(S= TRING) one.

On Fri, Jan 30, 2015 at 12:38 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

http:= //tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-1.1 uses this notation:

=C2=A0

=C2=A0=C2=A0 UTF8(STRING) denotes the octets of the UTF-8 [RFC3629] representation

=C2=A0=C2=A0 of STRING, where STRING is a sequence of zero or m= ore Unicode

=C2=A0=C2=A0 [UNICODE] characters.

=C2=A0

=C2=A0=C2=A0 ASCII(STRING) denotes the octets of the ASCII [RFC20] representation

=C2=A0=C2=A0 of STRING, where STRING is a sequence of zero or m= ore ASCII

=C2=A0=C2=A0 characters.

=C2=A0

This is unambiguous and has already b= een vetted by the IESG and SecDir, so I would use exactly this wording.<= /u>

=C2=A0

OCTETS(STRING) is ambiguous, since fo= r the same string there are many possible representations as octets, includ= ing ASCII, UTF-8, UTF-16, UTF-32, and EBCDIC.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Friday, January 30, 2015 11:33 AM
To: Brian Campbell
Cc: oauth; Naveen Agarwal
Subject: Re: [OAUTH-WG] PKCE: SHA256(WAT?)

=C2=A0

Have a look at the latest version I added OCTETS(STR= ING) to show the conversion. =C2=A0 ASCII(STRING) seemed more confusing by = drawing character encoding back in.

=C2=A0

I was tempted to call it a octet array without the t= erminating NULL of STRING but didn=E2=80=99t want to introduce array.

=C2=A0

Let me know what you think.

=C2=A0

On Jan 30, 2015, at 1:56 PM, Brian Campbell <bcampbell@pingi= dentity.com> wrote:

=C2=A0

But, while it may be clear to you, what I'm sayi= ng here is that it's not clear to a reader/implementer.

Somehow the conversion from a character string to an octet string needs to = be clearly and unambiguously stated. It doesn't have to be the text I s= uggested but it's not sufficient as it is now.

Something like this might work, if you don't want to touch the parts in= 4.2 and 4.6: "SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of = the octets of the ASCII [RFC0020] representation of STRING."

An "octet sequence using the url and filename safe Alphabet [...], wit= h length less than 128 characters." is ambiguous. Octets and character= s are intermixed with no mention of encoding. But they're not interchan= geable.

=C2=A0

=C2=A0

On Fri, Jan 30, 2015 at 7:15 AM, Nat Sakimura <sakimura@gmail.com> wrote:

I do not think we need ASCII(). It is quite clear wi= thout it, I suppose.=C2=A0

=C2=A0

In 4.1, I would rather do like:=C2=A0<= /p>

=C2=A0

=C2=A0code_verifier =3D high entropy cryptographic r= andom=C2=A0
=C2=A0=C2=A0 octet sequence using the url and filename safe Alphabet [A-Z] = / [a-z]
=C2=A0=C2=A0 / [0-9] / "-" / "_" from Sec 5 of RFC 4648= [RFC4648], with length
=C2=A0=C2=A0 less than 128 characters.

=C2=A0

Nat

=C2=A0

2015-01-30 22:51 GMT+09:00 Brian Campbell <bcampbell@pingide= ntity.com>:

That's definitely= an improvement (to me anyway).

Checking that the res= t of the document uses those notations appropriately, I think, yields a few= other changes. And probably begs for the "ASCII(STRING) denotes the o= ctets of the ASCII representation of STRING" notation/function, or something like it, to be put back in. Those changes = might look like the following:

In 4.1.:

OLD:
=C2=A0=C2=A0 code_verifier =3D high entropy cryptographic random ASCII [RFC= 0020]
=C2=A0=C2=A0 octet sequence using the url and filename safe Alphabet [A-Z] = / [a-z]
=C2=A0=C2=A0 / [0-9] / "-" / "_" from Sec 5 of RFC 4648= [RFC4648], with length
=C2=A0=C2=A0 less than 128 characters.

NEW (maybe):
=C2=A0 code_verifier =3D high entropy cryptographically strong random STRIN= G
=C2=A0 using the url and filename safe Alphabet [A-Z] / [a-z]
=C2=A0=C2=A0 / [0-9] / "-" / "_" from Sec 5 of RFC 4648= [RFC4648], with length
=C2=A0=C2=A0 less than 128 characters.


In 4.2.:

OLD:
=C2=A0=C2=A0 S256=C2=A0 "code_challenge" =3D BASE64URL(SHA256(&qu= ot;code_verifier"))

NEW (maybe):
=C2=A0=C2=A0 S256=C2=A0 "code_challenge" =3D BASE64URL(SHA256(ASC= II("code_verifier")))

In 4.6.:

OLD:
=C2=A0=C2=A0 SHA256("code_verifier" ) =3D=3D BASE64URL-DECODE(&qu= ot;code_challenge").

NEW (maybe):
=C2=A0=C2=A0 SHA256(ASCII("code_verifier")) =3D=3D BASE64URL-DECO= DE("code_challenge").

=C2=A0

=C2=A0

On Thu, Jan 29, 2015 at 8:37 PM, Nat Sakimura (=3Dna= t) <nat@sakimura.o= rg> wrote:

I take your point, Brian.=C2=A0

=C2=A0

In our most recent manuscript, STRING is defined ins= ide ASCII(STRING) as=C2=A0

=C2=A0

STRING is a sequence of zero or more ASCII characte= rs

=C2=A0

but it is kind of circular, and we do not seem to use ASCII().=C2=A0=

=C2=A0

What about re-writing the section like below?=C2=A0=

=C2=A0

STRING denotes a sequence of zero or more ASCII =C2=A0[RFC0020]=C2=A0characters.=C2=A0

OCTETS denotes a sequence of zero or more octets.=C2=A0

BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per=C2=A0Section 3=C2=A0produc= ing a ASCII[RFC0020]=C2= =A0STRING.

BASE64URL-DECODE(STRING) denotes the base64url decoding of STRING, per=C2= =A0Section 3, producing a sequence of octets.

SHA256(OCTETS) denotes a SHA2 256bit hash=C2=A0[RFC6234]=C2=A0of OCTETS.<= /p>

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Jan 30, 2015, at 08:15, Brian Campbell <bcampbell@pingide= ntity.com> wrote:

=C2=A0

In =C2=A72 [1] we'= ;ve got "SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of STRING= ."

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

Should it say somethi= ng more like "SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of t= he 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 th= is but maybe an example showing the computation steps on both ends would be helpful?

=C2=A0

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= decoding of STRING, per Section 3, producing a UTF-8 sequence of octets.&q= uot; But what is a UTF-8 sequence of octets? Isn't it just a sequence o= ctets? The [RFC3629] reference, I think, could be removed.

=C2=A0

Nat Sakimura=

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0



=C2=A0

--

Nat Sakimura (=3Dnat)<= u>

Chairman, OpenID Found= ation
http://nat.sakimura.= org/
@_nat_en

=C2=A0

=C2=A0


--20cf30223d83a8f18d050de44685--