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

Ludwig Seitz <> Tue, 17 December 2019 16:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4E4DD12007C; Tue, 17 Dec 2019 08:52:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CDVY-ULUhuDa; Tue, 17 Dec 2019 08:52:55 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6C37512002F; Tue, 17 Dec 2019 08:52:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; 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 [] ([]) by (mrgmx104 []) with ESMTPSA (Nemesis) id 1MJE6F-1iNoCG04c7-00KiL3; Tue, 17 Dec 2019 17:52:51 +0100
References: <>
From: Ludwig Seitz <>
Message-ID: <>
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: <>
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: <>
Subject: Re: [Gen-art] [Ace] Genart last call review of draft-ietf-ace-oauth-params-06
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Dec 2019 16:52:58 -0000

Hello Elwyn,

thank you for your review. Comments inline.


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

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

> 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