[Gen-art] Genart last call review of draft-ietf-ace-oauth-params-06

Elwyn Davies via Datatracker <noreply@ietf.org> Sat, 14 December 2019 22:46 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: gen-art@ietf.org
Delivered-To: gen-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3D21200A1; Sat, 14 Dec 2019 14:46:05 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Elwyn Davies via Datatracker <noreply@ietf.org>
To: gen-art@ietf.org
Cc: last-call@ietf.org, draft-ietf-ace-oauth-params.all@ietf.org, ace@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.113.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Elwyn Davies <elwynd@dial.pipex.com>
Message-ID: <157636356557.14894.14267145373083139598@ietfa.amsl.com>
Date: Sat, 14 Dec 2019 14:46:05 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/7i-5bvrRdn__QLlpopWPUvOmGMk>
Subject: [Gen-art] Genart last call review of draft-ietf-ace-oauth-params-06
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Dec 2019 22:46:06 -0000

Reviewer: Elwyn Davies
Review result: Not Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-ace-oauth-params-06
Reviewer: Elwyn Davies
Review Date: 2019-12-14
IETF LC End Date: 2019-12-13
IESG Telechat date: Not scheduled for a telechat

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<">https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;.

Document: draft-ietf-ace-oauth-params-06
Reviewer: Elwyn Davies
Review Date: 2019/12/14
IETF LC End Date: 2019/2/13
IESG Telechat date: (if known) N/A

Summary: Not ready.  In particular there seems to be some doubt as to whether
the definitions in this document are actually stable - or alternatively that it
lacks a versioning mechanism to cope with changes that the might be.

Major issues:
Dealing with possible updates to items defined here:
In s1 the following appears:

    These parameters and claims can also be used in other contexts, and may
    need to be updated to align them with ongoing OAuth work. Therefore, these
    parameters and claims have been put into a dedicated document, to
    facilitate their use and any potential updates in a manner independent of
    [I-D.ietf-ace-oauth-authz].

I am unclear whether this implies that it is intended that these potential
updates would alter the definitions here after they have been standardized or
alternatively that the standardization of this document should be delayed until
the alternative usage is defined.  If the first case applies, I do not see any
versioning mechanism that would allow early implementations to cope with later
updates of the items defined here.  In the second case, I have to ask myself
why this document has been submitted for standardization before the usages have
stabilized.

Minor issues:
ss3.1, 3.2 and 4.1:  The COSE_Key type 'EC' used in several kty fields is not
defined.  I assume it should be 'EC2'.

ss3.1, 3.2 and 4.1:  Does it matter that the definitions of the x and y
parameters in an EC2 key are given as 'h' encodings in RFC8152 but are given as
'b64' in this document?  I am very much not an expert here.

s6: This section starts with 'If CBOR is used...': The main ACE draft
draft-ietf-ace-oauth-authz is apparently intended to cover both JSON and CBOR
encodings of payloads, although CBOR is recommended.  This is not made explicit
in this addition to that specification and the use of CBOR diagnostic
representation and the prominence of COSE_Key items could make it appear up
until s6 that this specification is intended just for CBOR encoding.  A few
words at the beginning would clarify the dual alternatives.

Nits/editorial comments:
General: s/e.g./e.g.,/ (3 places)

Abstract, 2nd sentence: s/whishes/wishes/

Abstract: Need to expand AS and RS.

s2:  RS, AS and (probably) various other terms are defined in RFC 6749 and need
to be expanded on  first use.  Adding something like the para from
draft-ietf-ace-oauth-authz would solve this (except for the abstract).

    Terminology for entities in the architecture is defined in OAuth 2.0
    [RFC6749] such as client (C), resource server (RS), and authorization
    server (AS).s2, para 3: Need to expand CoAP on first use.

s3:  This section needs a reference to RFC 8152 for the specification of the
CWT COSE_Key item that is used extensively.

s3/s4: Some introductory text for each section is desirable.

s3.1, para 2 (definition of req_cnf):: Possibly add a note that the
recommendation against symmetric keys implies currently kty being 'Symmetric'. 
Will it ever be anything else?

s3.1:  The text in s3.2 of draft-ietf-ace-cwt-proof-of-possession-03 contans
the following

   The COSE_Key MUST contain the required key members for a COSE_Key of that
   key type and MAY contain other COSE_Key members, including the "kid" (Key
   ID) member.

   The "COSE_Key" member MAY also be used for a COSE_Key representing a
   symmetric key, provided that the CWT is encrypted so that the key is not
   revealed to unintended parties. The means of encrypting a CWT is explained
   in [RFC8392]. If the CWT is not encrypted, the symmetric key MUST be
   encrypted as described in Section 3.3.

These riders probably apply to all the subsectons of s3 and to s4.1 and could
be included in the currently empty main section text.

s4.1, rs_cnf - DTLS-RPK: This term needs a reference (RFC 7250). Also all other
uses do not hyphenate and RPK needs to be expanded.
   s/DTLS-RPK handshake/DTLS Raw Public Key (RPK) handshake [RFC7250]/