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

Ludwig Seitz <ludwig_seitz@gmx.de> Tue, 17 December 2019 16:52 UTC

Return-Path: <ludwig_seitz@gmx.de>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4DD12007C; Tue, 17 Dec 2019 08:52:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 CDVY-ULUhuDa; Tue, 17 Dec 2019 08:52:55 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C37512002F; Tue, 17 Dec 2019 08:52:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576601571; bh=c9d+xk1QPzKfC7vDjZu3y5w4ckX62ZxwsBoV1iGzGLg=; h=X-UI-Sender-Class:Subject:To:References:Cc:From:Date:In-Reply-To; b=kRotzttMNl7nMDyJgWO4VSi8D2QVIeJnBILB5v1bB3q7+WkafvRxk3SNAfKtE+Wey JoboTYeAzcTxEdyNQnEIYJTqD3/wLto/5Uu/4pPDr4cSGicwGNGPEH+dYAz2zA3J1Z DYvyhGbAUTTWkhuEOytg9rX5n8m+XCyLvqGGcelI=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.220] ([84.217.44.37]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MJE6F-1iNoCG04c7-00KiL3; Tue, 17 Dec 2019 17:52:51 +0100
To: elwynd@dial.pipex.com
References: <157636356557.14894.14267145373083139598@ietfa.amsl.com>
Cc: ace@ietf.org, gen-art@ietf.org, last-call@ietf.org
From: Ludwig Seitz <ludwig_seitz@gmx.de>
Message-ID: <6da3360a-157e-e3cf-d1ea-109d8515da42@gmx.de>
Date: Tue, 17 Dec 2019 17:52:50 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <157636356557.14894.14267145373083139598@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:fKPO6uXBZwk7PnVx2MZn8qVJVdEv2pB19gQAVVN3T5AMJcEvrzV P7yKBG6CNbAQ2H6sg17GTq2bDa5LkE0aUIzKYEG6vZMe7dLZHrff4TFgXtTfUC5y9EzNrcP iZNrByaTE+oHTUeEIz1jRdcde7R/X3ZDZ8x7a0ym5eihO5jC0hAZSQoosRb/ApaQstaK+gz oEGF+igAVl8OJVnUfqQIA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:Cl3qiFYRSEE=:sJT8nuD8kkPNu0OvbXO+8m syumei06wDWLeo9gBNB8VTi3DazeCrNu1U5J34dM5xnW/lST8dfeeeSe6/SN3V8kezDhW8wPp +Zzgzey67XlY+h+pEnJX0j9GuJhpCgWNPXFw9lazSlLlsk53akmFevG6J45ov8RM3X4UvWQtC WyrgV7dmkR3CfF37RWrAwvvw1uos6kIXubbhOAoGoqPrn7buKHHqgA9AvUR8W5SRZIIW4c/d+ qTgytMNAGAj5mmJ9axZGjyMyNmBtFfc8ZjE4RRnieDWeH48lyuVp1MkGXF4C8lFw6t9PpDIKp m+CDPi+BhlO5tCS6oT8O1EQaXnbLdbjmiOcBHdGAcjBahp2MO41G9GEq1tB9GVHRD63ZESLCY xZu4mLaIG6yXilKOnK9pi3yDxcVIHbU/Hyjx3RrRLFQTxjGSIMpKxz7bEIKjW13MSiblNvEDV dDtu199AJfJODoqC9nanRmF/ze9ukFr3554TuDpulmfX7e/Os7bMbHFw1lcAERfchwyR8ipaK MVSru+eFwcOI9S5FVW6R7Vpf1tvb0B4066xzGcfLD9OihwrtO8octegCtop9A3/nPOurCjo1b trwveJIuKE7xUVGzAyu6LjyPe8NGalLQt6/k2aYyO9TABAqjnJXl3dIibWo0gvMvvA9FankMA /2R/GM8E+IVxbChmuY3oDaTqdVyNxI6I+E1nr5r+ePVLRqpp+XY2sUCPhXoA/2ae+eiullspY qZLQktHpmsYITXviHDvLFOuFLF24Qewzlbfp3BHjC7kyLq664GAcN0NzHjd2cZZlnwhsNkr+p NbXjY6gJSFE8+CsdC53Hco6tJGTP/2aDJ/m+IdocMd0JDNlJXINONjRSgUkSEuiGbhELsEbPm miVoWT/oIHAXiN9r+T84ffr652110kW+6UGYyuo1xOtkmVJpAhsJ6xjLrVLFefbQYWABMRKwz A+lHbFWkUSIm9kJtEZV/2ZRDfVp76n23NXCFUAkYjT3f1IsVrQtlhYEuREjfnFpdzu8U4rqAZ Pu4nF2f+hkfKg/qm/d/qAf9MVgj2GVEyB9HFH+1nr8x0Z+20RL6/OpDVOn826EDLap3Re7nww f6dgKAFx2A375ic/p/zW+leB9HxRvEJQWlw9qXAlGe870Q7ARJmjLJCeHlR7N01M7EYHpLqoG O15aAglE+jphoQ5vzWc5PIiTvi40Zpi99H7LtEAIwcnvJk1XCe76OSboGcPWb1vME1sVTYSek w2Zvn6tZW7Qlh/y6/S0AtvWiX95zv5NFGuEV7uduVufHvjK6itXwAfxqcZjc=
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/sRi1Hq7o3FtMibZjMB3HJvKTuHs>
Subject: Re: [Gen-art] [Ace] Genart last call review of draft-ietf-ace-oauth-params-06
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Tue, 17 Dec 2019 16:52:58 -0000

Hello Elwyn,

thank you for your review. Comments inline.

/Ludwig


On 2019-12-14 23:46, Elwyn Davies via Datatracker wrote:
> 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.
>

The intention with this document was to place certain parameters
(req_cnf, cnf, rs_cnf) needed for draft-ietf-ace-oauth-authz into a
separate document, that could be updated or obsoleted by other drafts
without obsoleting or updating draft-ietf-ace-oauth-authz.

This is mainly due to some work in the OAuth WG which has been running
in parallel, especially
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution.

Since this is not a high priority item for OAuth (the draft named above
has expired), the feeling in ACE was (@ACE please correct me if I
misrepresent) that going forward with this document was a good
compromise to get these parameters standardized, while causing minimal
breakage if OAuth at some later point finalized the pop key distribution
work.


> 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'.
>
Correct, will fix

> 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.

This is just a matter of the diagnostic representation used here for
human readability. On the wire this will be the same binary string.

Note that the hex encoding h'....' renders a much longer string than the
Base64 encoding b64'...' so I prefer b64 for readability.
>
> 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.
>
I will add a clarification. The intention is to cover both JSON and CBOR.


> Nits/editorial comments:

Will fix.

> 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]/
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>