Re: [Ace] New Version Notification - draft-ietf-ace-cwt-proof-of-possession-07.txt

Benjamin Kaduk <kaduk@mit.edu> Tue, 24 September 2019 23:35 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA441201AA; Tue, 24 Sep 2019 16:35:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 7Sr6q1Rzb0q3; Tue, 24 Sep 2019 16:35:15 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 DD037120845; Tue, 24 Sep 2019 16:35:14 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x8ONZA00006963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Sep 2019 19:35:13 -0400
Date: Tue, 24 Sep 2019 16:35:10 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: draft-ietf-ace-cwt-proof-of-possession.all@ietf.org
Cc: ace@ietf.org
Message-ID: <20190924233510.GI6424@kduck.mit.edu>
References: <156886195825.4610.11342453288215138739.idtracker@ietfa.amsl.com> <20190924233318.GH6424@kduck.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190924233318.GH6424@kduck.mit.edu>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/c4gum8GBuhduN6nEnL6HiVbVwrw>
Subject: Re: [Ace] New Version Notification - draft-ietf-ace-cwt-proof-of-possession-07.txt
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Sep 2019 23:35:17 -0000

On Tue, Sep 24, 2019 at 04:33:18PM -0700, Benjamin Kaduk wrote:
> Hi all,
> 
> Thanks for the updates; they look good!
> 
> Before I kick off the IETF LC, I just have two things I wanted to
> double-check (we may not need a new rev before the LC):
> 
> (1) In Section 3.2 (Representation of an Asymmetric Proof-of-Possession
> Key), the last paragraph is a somewhat different from the main content, in
> that it mentions using "COSE_Key" for an encrypted symmetric key, analogous
> to the last paragraph of Section 3.2 of RFC 7800.  I had wanted to see some
> additional discussion, but we agreed that this was analogous to RFC 7800
> and we did not need to go "out of parity" with it on this point.  So we
> should be able to go ahead without new text here, but did we want to
> explicitly refer back to that portion of RFC 7800 to make the connection
> clear?
> 
> (2) In https://github.com/cwt-cnf/i-d/pull/27/files we removed a large
> chunk of text since it contained several things that are inaccurate.  The
> only things that were removed that I wanted to check if we should think
> about keeping was the note that the same key might be referred to by
> different key IDs in messages directed to different recipients.  What do
> people think about that?

Oops, and my notes were unfortunately misalgined to the terminal window
size:

(3) I think we were going to change the [JWT] reference to [CWT], in
Section 4:

   Applications utilizing proof of possession SHOULD also utilize
   audience restriction, as described in Section 4.1.3 of [JWT], as it
   provides additional protections.  Audience restriction can be used by
   recipients to reject messages intended for different recipients.

That way we won't get asked to make [JWT] a normative reference.

-Ben