Re: [OAUTH-WG] draft-ietf-oauth-spop-10

Nat Sakimura <> Wed, 18 February 2015 04:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1CF861A8982 for <>; Tue, 17 Feb 2015 20:14:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 4.607
X-Spam-Level: ****
X-Spam-Status: No, score=4.607 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FSL_HELO_BARE_IP_2=1.999, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sRbuW5RdSwWD for <>; Tue, 17 Feb 2015 20:14:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B33E91A0163 for <>; Tue, 17 Feb 2015 20:14:14 -0800 (PST)
Received: from (unknown []) by (Postfix) with SMTP id CA814196871; Wed, 18 Feb 2015 13:14:13 +0900 (JST)
Received: from ([]) by (unknown) with ESMTP id t1I4EDGI014666; Wed, 18 Feb 2015 13:14:13 +0900
Received: from (localhost.localdomain []) by (Switch-3.3.3/Switch-3.3.3) with ESMTP id t1I4ED6q023994; Wed, 18 Feb 2015 13:14:13 +0900
Received: (from mailnull@localhost) by (Switch-3.3.3/Switch-3.3.0/Submit) id t1I4ED9g023993; Wed, 18 Feb 2015 13:14:13 +0900
X-Authentication-Warning: mailnull set sender to using -f
Received: from ([]) by (Switch-3.3.3/Switch-3.3.3) with ESMTP id t1I4EDGP023988; Wed, 18 Feb 2015 13:14:13 +0900
Received: from ( by m-FILTER with ESMTP; Wed, 18 Feb 2015 13:14:13 +0900
Date: Wed, 18 Feb 2015 13:13:59 +0900
From: Nat Sakimura <>
To: Hannes Tschofenig <>
Message-Id: <>
In-Reply-To: <>
References: <>
X-Mailer: Sylpheed 3.4.2 (GTK+ 2.10.14; i686-pc-mingw32)
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-MailAdviser: 20141126
Archived-At: <>
Cc: "" <>,
Subject: Re: [OAUTH-WG] draft-ietf-oauth-spop-10
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: Wed, 18 Feb 2015 04:14:17 -0000

Hi Hannes, 

I hereby confirm that I have submit the draft  in full conformance with the  provisions of BCP 78 and BCP 79.

Re: Security Consideration (7.1) and section 4.1

The first part of the 7.1 is a non-normative prose explaining that the implementers got to make sure that the code verifier is hard to guessed or modeled. In a way, this is laying out the basic security property requirment on the code verifier. 

Then, it goes onto the implementation guideance that one need to use a cryptographic random number generator instead of relying on a rand() in some language that are  not cryptographically random to generate 32-octet sequence. The same text is in 4.1 as well. 

We did not copy "code verifier SHOULD have enough entropy to make it impractical to guess the value" here because that looked needlessly repeating, but if you want, I have no objection in adding it to 7.1. 

Alternatively, in 7.1, after explaining the rationale, we can just point to 4.1 for the control and implementation guidance. 

Re: 32-octet

We chose it because we are using SHA256 in generating the code challange.
Having more entropy does not help us here, while having less octets increases the risk. 



On Tue, 17 Feb 2015 17:56:33 +0100
Hannes Tschofenig <> wrote:

> Hi Nat, John, Naveen,
> thanks a lot for your work on the document.
> I still need responses to this mail to complete the shepherd writeup:
> I definitely need the IPR confirmation.
> It would also be helpful to have someone who implemented the
> specification as it currently is. I asked Brian and Thorsten for
> clarification regarding their statements that they implemented earlier
> versions of the spec.
> As a final remark I still believe that the text regarding the
> randomness is still a bit inconsistent. Here are two examples:
> 1) In the Security Consideration you write that "The security model
> relies on the fact that the code verifier is not learned or guessed by
> the attacker.  It is vitally important to adhere to this principle. "
> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD
> have enough entropy to make it impractical to guess the value.  It is
> RECOMMENDED that the output of a suitable random number generator be
> used to create a 32-octet sequence."
> There is clearly a long way from a SHOULD have enough entropy to the
> text in the security consideration section where you ask for 32 bytes
> entropy.
> It is also not clear why you ask for 32 bytes of entropy in
> particular.
> Ciao
> Hannes

Nat Sakimura (
Nomura Research Institute, Ltd. 

信されたメールを削除していただきますようお願い致します。 PLEASE READ:
The information contained in this e-mail is confidential and intended
for the named recipient(s) only. If you are not an intended recipient
of this e-mail, you are hereby notified that any review, dissemination,
distribution or duplication of this message is strictly prohibited. If
you have received this message in error, please notify the sender
immediately and delete your copy from your system.