[OAUTH-WG] Nits regarding draft-ietf-oauth-spop-06.txt
Hannes Tschofenig <hannes.tschofenig@gmx.net> Tue, 27 January 2015 16:15 UTC
Return-Path: <hannes.tschofenig@gmx.net>
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 CB7981A8831 for <oauth@ietfa.amsl.com>; Tue, 27 Jan 2015 08:15:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 jDiA5s8P1kVC for <oauth@ietfa.amsl.com>; Tue, 27 Jan 2015 08:15:56 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAF991A017D for <oauth@ietf.org>; Tue, 27 Jan 2015 08:15:55 -0800 (PST)
Received: from [192.168.131.153] ([80.92.115.149]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M3igT-1XP01I0Qgj-00rDY7 for <oauth@ietf.org>; Tue, 27 Jan 2015 17:15:53 +0100
Message-ID: <54C7BA9A.4010501@gmx.net>
Date: Tue, 27 Jan 2015 17:19:38 +0100
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "oauth@ietf.org" <oauth@ietf.org>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="MnqtmJET0rJKQNkVvimSueCTQCkwCV4ED"
X-Provags-ID: V03:K0:lwuop947lsFabZD6uJg4VoyeG5P4C3R1wLUCQw8yarUg6Xceh0v iHIemFTZX+IJOIuGfJs0W1RH5x0Abn26ajW+CqB9iDePPP66QAokhFGVSlaPxjuIWUDlvBE A718vCfCYPhQmFXGDU/GAMlfInaJHWx0SYuhQuEdjWr028kmXpX4Huxee0eqXPwHVyQ3QSh PSJAfITnDlRUhtHYzMo0g==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/VeVmu4c7w6NAToeAD7_34zZQXFg>
Subject: [OAUTH-WG] Nits regarding draft-ietf-oauth-spop-06.txt
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: Tue, 27 Jan 2015 16:15:57 -0000
Hi Nat, Hi John, Hi Naveen, Hi all, in the appendix you include C# code. I was wondering where the code came from? Did you write the code or did you copy it from somewhere else? This question is relevant from a copyright point of view. RFC 5226 is mentioned in the document but missing in the informative reference section. A minor wording suggestion for the following paragraph: " All the OAuth security analysis presented in [RFC6819] applies so readers SHOULD carefully follow it. " I think the RFC 2119 language use of the word 'SHOULD' isn't appropriate here. I think it would be better to just say the following: " The OAuth security analysis presented in [RFC6819] applies to this document. Implementers are strongly encouraged to follow the recommended security practice. " (I guess it is not possible to highlight a few aspects since the entire document, i.e., RFC 6819, may be relevant depending on the chosen OAuth features.) I noticed a funny thing about the ABNF. When I used this ABNF code " ALPHA = %x41-5A / %x61-7A DIGIT = %x30-39 code_verifier = 42*128unreserved unreserved = ALPHA / DIGIT / "-" / "_" " I get an error from 'Bill's ABNF Parser'. The tool complains about the use of the "_" in the code_verifier label. It turns out that this is not an allowed token in ABNF as defined in RFC 5234 (at least that's my current understanding). Of course that is a bit inconvenient since we have been using "_" already in many OAuth parameters before, as the IANA OAuth parameter registry shows: http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml So, I hope that my understanding of ABNF is incorrect since otherwise we have messed things up a bit (at least when it comes to compliance with the ABNF syntax). This does, of course, not have any impact on implementations. Feedback appreciated. Ciao Hannes
- [OAUTH-WG] Nits regarding draft-ietf-oauth-spop-0… Hannes Tschofenig