[OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-proof-of-possession-10: (with COMMENT)

"Stephen Farrell" <stephen.farrell@cs.tcd.ie> Thu, 17 December 2015 11:45 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3B81B2B92; Thu, 17 Dec 2015 03:45:18 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.11.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151217114518.32317.77951.idtracker@ietfa.amsl.com>
Date: Thu, 17 Dec 2015 03:45:18 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/i08di7i8Qbp55YxWqisY6X0TlWg>
Cc: oauth@ietf.org, draft-ietf-oauth-proof-of-possession@ietf.org, oauth-chairs@ietf.org
Subject: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-proof-of-possession-10: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 17 Dec 2015 11:45:19 -0000

Stephen Farrell has entered the following ballot position for
draft-ietf-oauth-proof-of-possession-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


- Figure 1 and the discussion thereof: you talk all the time here
about "a symmetric key" so I think you ought add a footnote like
bit of text that says something like "note that there ought be
more than one key involved here, derived from the key exchanged
at (0) via a KDF." I kinda wish that all that had been covered in
one document but I guess that's part of the PoP arch doc, which
is for later.

- 3.1 says "outside the scope of this specification": just
wondering - does that phrase occur in all OAuth RFCs? (only
kidding, honest:-)

- section 4, para 2: replay can also be avoided if a sub-key is
derived from a shared secret that is specific to the instance of
the PoP demonstration.

- section 6: DE guidance - I think we ought tell the DEs that the
specification of a new thing needs to explicitly describe the
security properties of using the new thing.

- I didn't see a response to the secdir review [1] but that was
maybe sent to the wrong places. 

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06266.html