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

elwynd <> Sun, 22 December 2019 18:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AED09120026; Sun, 22 Dec 2019 10:39:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.194
X-Spam-Status: No, score=-4.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iXj7CRKEJY7i; Sun, 22 Dec 2019 10:39:08 -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 F4180120019; Sun, 22 Dec 2019 10:39:07 -0800 (PST)
Received: from ([2001:8b0:bf:1:c548:d2c2:ce5a:9859]) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1ij5wt-0004Yd-1F; Sun, 22 Dec 2019 18:27:27 +0000
Date: Sun, 22 Dec 2019 18:27:22 +0000
In-Reply-To: <>
Importance: normal
From: elwynd <>
To: Ludwig Seitz <>, Elwyn Davies <>,
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=""
Message-ID: <>
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: Sun, 22 Dec 2019 18:39:11 -0000

Hi, Ludwig.Having had another look at section 3.1 of draft-ietf-ace-cwt-proof-of-possession, technically the rules about which keys have to be present are not part of the syntax of the cnf claim.  The point can be covered by changing '"syntax of the 'cnf' claim"to "syntax and semantics of the 'cnf' claim"in each case.However, the second look threw up another point:  Figure 2 in s3.2 gives a Symetric key example  - I think this should use an Encrypted_COSE_Key (or Encrypted_COSE_Key0) as described in section 3.3 of draft-ietf-ace-cwt-proof-of-possession.Otherwise I think we are done.Eventually we will get to Christmas!  Cheers,ElwynSent from Samsung tablet.
-------- Original message --------From: Ludwig Seitz <> Date: 22/12/2019  12:36  (GMT+00:00) To: Elwyn Davies <>om>, Cc:,, Subject: Re: [Gen-art] [Ace] Genart last call review of
  draft-ietf-ace-oauth-params-06 Hello Elwyn,I have now submitted -09 to fix the minor issues and nits, which Iforgot in my -08.Comments inline.Regards,LudwigOn 2019-12-14 23:46, Elwyn Davies via Datatracker wrote:<deleted>> 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.>Here I disagree. The text explicitly refers todraft-ietf-ace-cwt-proof-of-possession, saying that the contents of the'cnf', 'req_cnf' and 'rs_cnf' parameters use the syntax of the 'cnf'claim from section 3.1 of draft-ietf-ace-cwt-proof-of-possession.The requirements in section 3.2 draft-ietf-ace-cwt-proof-of-possessionfollow from the use of the definitions in 3.1.I don't see the value of reiterating such a long text from that documenthere, when an explicit reference is already given._______________________________________________Gen-art mailing listGen-art@ietf.org