Re: [Lake] COSE IANA registrations in EDHOC (Was: New Version Notification for draft-ietf-lake-edhoc-09.txt)

Benjamin Kaduk <kaduk@mit.edu> Wed, 01 September 2021 04:19 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: lake@ietfa.amsl.com
Delivered-To: lake@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D113A11AD; Tue, 31 Aug 2021 21:19:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 rPlKByI5oDUw; Tue, 31 Aug 2021 21:19:08 -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 4874C3A11A0; Tue, 31 Aug 2021 21:19:08 -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 1814IuRJ014879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 1 Sep 2021 00:19:02 -0400
Date: Tue, 31 Aug 2021 21:18:55 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Göran Selander <goran.selander=40ericsson.com@dmarc.ietf.org>
Cc: Carsten Bormann <cabo@tzi.org>, "lake@ietf.org" <lake@ietf.org>, Michael Richardson <mcr@sandelman.ca>, "cose@ietf.org" <cose@ietf.org>
Message-ID: <20210901041855.GI96301@kduck.mit.edu>
References: <F24FD33B-B94D-4C84-AE07-C9161668C16E@ericsson.com> <C5080F76-EE94-47A7-AEF7-864C7644BE8F@tzi.org> <D7EE1E0A-2EE4-4A47-AAC3-215C74C33CC3@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <D7EE1E0A-2EE4-4A47-AAC3-215C74C33CC3@ericsson.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/rS7I3nuMKjUCdEOKj4kkOHeBRQw>
Subject: Re: [Lake] COSE IANA registrations in EDHOC (Was: New Version Notification for draft-ietf-lake-edhoc-09.txt)
X-BeenThere: lake@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Lightweight Authenticated Key Exchange <lake.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lake>, <mailto:lake-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lake/>
List-Post: <mailto:lake@ietf.org>
List-Help: <mailto:lake-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lake>, <mailto:lake-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Sep 2021 04:19:14 -0000

On Tue, Aug 24, 2021 at 11:43:42AM +0000, Göran Selander wrote:
> 
> 
> > On 2021-08-24, 10:05, "Lake on behalf of Carsten Bormann" <lake-bounces@ietf.org on behalf of cabo@tzi.org> wrote:
> >
> >    I see.
> >
> >    So, you are saying, this will be a “using EDHOC in COSE” specification, 
> 
> Well, others may also have use of the COSE header for CWT/UCCS, and the int value type of 'kid'.
> 
> >  still normative, but referenced from EDHOC as informative as 
> >   EDHOC works without COSE.
> 
> Well, EDHOC is definitely dependent on COSE, but does not require these particular credentials or identifiers.
> 
> >   Yes, it is always hard to position a “using X in Y” draft between the X and Y working groups — after all, the two ends of this draft need 
> >   to fit X and Y, respectively.  If the EDHOC specification truly doesn’t need the contents of this specification, then I can see moving them
> >   into a COSE document.  But I think it is as expedient to keep them together in one document.  The only strong reason to split the 
> >  document would be to avoid a long wait while COSE is deciding on some controversial content of the extracted spec.  Do we foresee such 
> >  a delay?
> 
> Not that I am aware of. Previous discussion in COSE has not indicated that this is contentious. The main thing we haven't discussed is that EDHOC would be updating rfc8152bis-struct.

I think it would invite questions of charter scope if a document from LAKE
attempted to update rfc8152bis-struct; keeping that work in COSE seems
likely to have an easier path, process-wise.

-Ben