Re: [OAUTH-WG] PKCE/SPOP

William Denniss <wdenniss@google.com> Wed, 04 February 2015 01:50 UTC

Return-Path: <wdenniss@google.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 2831F1A1B9C for <oauth@ietfa.amsl.com>; Tue, 3 Feb 2015 17:50:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 884DxKuzclfS for <oauth@ietfa.amsl.com>; Tue, 3 Feb 2015 17:50:26 -0800 (PST)
Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28FF11A1B8E for <oauth@ietf.org>; Tue, 3 Feb 2015 17:50:26 -0800 (PST)
Received: by mail-oi0-f43.google.com with SMTP id z81so52198415oif.2 for <oauth@ietf.org>; Tue, 03 Feb 2015 17:50:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=075kAO84C7oPKwW5uX+7Mc+gNagtE5H6nyuFxJLClzk=; b=ZeNEZERWXZkq2iSjI4VFofIBijmusnpJ6wK0mO4PDBeB0P9n9Y6milGuAPjhe6Rlku gwK8JNbrP7BBDctnntQjO14wbVNqLv87PFIiZUCWNLf0W/BQZ+zlmZE3Xj5sEat+BNGM i3bHPXYtp3tJz++cHEuB8d1HVPJhYXpDsKLCYdgM/DWjYye9hdeN08jSVuSKkAdh2Hbi /FkrfuwDjZF7Rz1NWQbERFzINwGNW4xcBVbLFdg4MHFg0/+VXxL1yhjpzxyzc4W/G4f1 tWnE3GGTkODBM/3qAkJylzgxqdEzFkyH16VJEncDx9dVueSps+BmAVnxMqYY+WxD7XKH nAOg==
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=075kAO84C7oPKwW5uX+7Mc+gNagtE5H6nyuFxJLClzk=; b=eFK1wii36LghH4b8LFkotPgV/BOq/aBr+v88bwaGEbhy+nxV4EPMav+Jbbh8EisVfg ym0ikESVJdzTNFoSJZlW+cpQXipDHk42/U/f848RFyYhJPJA3Uunu2G24wK0jmoPEVB3 NloWirppXn2CaVaX//M3FnqxeE3v5Q5QgfeyMctWkT7O865pYarc8H+DLqb6XDrpYTFc xIC75j6yUhgVw0szeqg183y3LH5H+0msY/c1RyN8rN3TmHnslWuXt906kx/Y3OxnHApw 3giVRSBPNYsR3fJbedBQtLJssBwtd5wN84PEQDgkz2irUN876O8ZiMUqNukuyZUtR+9c tEew==
X-Gm-Message-State: ALoCoQkST2OvF7SawAcHz4dnuIuqQP5Nsr2cZy8jyB2pIhFwlEka4lfzvxDSkfTvGvlsR4QHAVrJ
X-Received: by 10.202.80.199 with SMTP id e190mr16577431oib.75.1423014625360; Tue, 03 Feb 2015 17:50:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.202.80.206 with HTTP; Tue, 3 Feb 2015 17:50:04 -0800 (PST)
In-Reply-To: <E57A72CF-C02A-47AA-B8CC-72795F57F3D8@ve7jtb.com>
References: <5CB2DAD4-1C61-4910-A866-4C18F4A9A3FE@ve7jtb.com> <CA+k3eCQmFsR95d+6Y0Ub=hVMdCB_siNMsKKrJYB3LXgsczfJrA@mail.gmail.com> <E57A72CF-C02A-47AA-B8CC-72795F57F3D8@ve7jtb.com>
From: William Denniss <wdenniss@google.com>
Date: Tue, 3 Feb 2015 17:50:04 -0800
Message-ID: <CAAP42hBSZz-t-VRg+2VTYwneO9wVTZDr9LCPhumTP3jtxZmPsQ@mail.gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary=001a113b1c00416881050e3969cd
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/nl5KP3mL1NnI96CbScjLQHXQgT8>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] PKCE/SPOP
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: Wed, 04 Feb 2015 01:50:28 -0000

Speaking of Base64url, where it's defined in "Notational Conventions", is
there a way to prevent the HTML markup automatically linkifying "Section
3.2" ?  It's not marked up in the XML, but in the HTML output it is – and
the auto-generated link is incorrect, as it points to Section 3.2 in SPOP,
rather than 3.2 in RFC4648.

This may seem trivial, but the fact that we're using a less common variant
of Base64url makes me want to provide as much accurate context as possible
to help implementers.

This is how it renders today (note the Section 3.2 link)

   Base64url Encoding  Base64 encoding using the URL- and filename-safe
      character set defined in Section 5 of RFC 4648
<http://tools.ietf.org/html/rfc4648#section-5> [RFC4648
<http://tools.ietf.org/html/rfc4648>], with all
      trailing '=' characters omitted (as permitted by Section 3.2
<http://tools.ietf.org/html/draft-ietf-oauth-spop-08#section-3.2>) and
      without the inclusion of any line breaks, whitespace, or other
      additional characters.  (See Appendix A
<http://tools.ietf.org/html/draft-ietf-oauth-spop-08#appendix-A> for
notes on implementing
      base64url encoding without padding.)



On Tue, Feb 3, 2015 at 6:51 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

> OK I fixed that in bitbucket.
>
> If I don’t hear back from anyone else I will push that version to the doc
> tracker this afternoon.
>
> John B.
>
>
> On Feb 3, 2015, at 10:40 AM, Brian Campbell <bcampbell@pingidentity.com>
> wrote:
>
> I went thought appendix B and reproduced the same calculations. Which is
> nice.
>
> One little nit - to be consitent with the notation defined in §2, the appendix
> B should have
>
>    BASE64URL(SHA256(ASCII("code_verifier"))) == code_challenge
>
> rather than
>
>    Base64url(SHA256(ASCII("code_verifier" ))) == code_challenge
>
>
>
>
> On Sun, Feb 1, 2015 at 5:07 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>
>>
>> https://bitbucket.org/Nat/oauth-spop/raw/cd8b86496fb59261103143c246658da06e99c225/draft-ietf-oauth-spop-00.txt
>>
>> I made some edits to the copy in bitbucket.
>>
>> I changed the reference for unreserved URI characters to RFC3986. The
>> Base64 spec we were pointing to is slightly different.
>> The change allows someone in the future to define a new
>> code_challenge_method that would allow a JWT to be valid.
>> We unintentionally precluded the use of the “.” in code_challenge and
>> code_verifier.
>>
>> I also added an appendix B to show the steps of S256 in a way someone
>> could use as a test vector.
>>
>> Appendix B is a first cut at it so give me feedback, and I can push it to
>> the document tracker later in the week.
>>
>>
>> John B.
>>
>>
>> _______________________________________________
>> 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
>
>