Re: [Ace] Charter discussion
Benjamin Kaduk <kaduk@mit.edu> Tue, 17 November 2020 23:47 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 645253A1044 for <ace@ietfa.amsl.com>; Tue, 17 Nov 2020 15:47:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 rKVcXc-sHKXg for <ace@ietfa.amsl.com>; Tue, 17 Nov 2020 15:47:08 -0800 (PST)
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 0842D3A1033 for <ace@ietf.org>; Tue, 17 Nov 2020 15:47:07 -0800 (PST)
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 0AHNl1d7005173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Nov 2020 18:47:05 -0500
Date: Tue, 17 Nov 2020 15:47:00 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Daniel Migault <mglt.ietf@gmail.com>
Cc: Ace Wg <ace@ietf.org>
Message-ID: <20201117234700.GR39170@kduck.mit.edu>
References: <CADZyTkmnV_Dhb5iXzykUyEAskLDg7tj=80CbEBGmSyFQNS2FHw@mail.gmail.com> <HE1PR0702MB36740BAAFD7FDA2688564BF7F4E60@HE1PR0702MB3674.eurprd07.prod.outlook.com> <CADZyTkkpLRvqD5Vx704u=qbRvE82o4cKk3Ff2Y2ZXes_B+nRbA@mail.gmail.com> <CADZyTkkSGiUvXf0NoVUwj0Vjf7AQ=pjdEHyHZsDdE67OvfTepw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CADZyTkkSGiUvXf0NoVUwj0Vjf7AQ=pjdEHyHZsDdE67OvfTepw@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/_Ftr1h3zoTY0stz2m7A0FX3BvN0>
Subject: Re: [Ace] Charter discussion
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, 17 Nov 2020 23:47:10 -0000
Thanks for updating the draft charter at [1], Daniel! I note that Michael raised the question of whether some other group might also be interested in working on CMP-over-coap, so the IESG will be sure to discuss that if CMP is still in the draft ACE charter when it goes to the IESG for review. -Ben On Tue, Nov 17, 2020 at 06:16:48PM -0500, Daniel Migault wrote: > Thank you all for the feed backs. For the purpose of driving the charter > discussion at the IETf 109, I have added the comments into the proposed > text [1]. > > My current understanding is that it seems beneficial to add CMPv2 over CoAP > in the charter. I am happy to be contradicted. > * I have not seen a clear cut to do one or the other. > * EST and CMPv2 are two protocols that can be used for enrollment or cert > management while addressing different cases / needs / situations -- maybe > we can clarify that point. I can see leveraging the existing CMP > infrastructure, but it seems that is not the only one. > * I am not convinced that not having CMP over CoAP will not prevent its > deployment and as such I prefer to have it standardized - this might be a > personal thought. > * Adding any piece of work require cycles, but it seems to me that CPM will > not have a major impact on the WG progress. The work will probably include > other WG such a LAMPS. > > Yours, > Daniel > > [1] > https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing > > On Tue, Nov 17, 2020 at 6:02 PM Daniel Migault <mglt.ietf@gmail.com> wrote: > > > Hi Goran, > > > > I added the text to the charter we will discuss later. > > > > Yours, > > Daniel > > > > On Fri, Nov 13, 2020 at 10:26 AM Göran Selander < > > goran.selander@ericsson.com> wrote: > > > >> Hi Daniel, > >> > >> > >> > >> Here’s another input to the charter. > >> > >> > >> > >> The current group key management solutions addresses the problem of > >> authorized access to group keys and public keys of group members. > >> > >> > >> > >> A related problem is authorized access of public keys of other devices > >> not necessarily part of a security group, in the sense of sharing a > >> symmetric key used to protect group messages. > >> > >> > >> > >> Authorized access to raw public keys serves an important function in > >> constrained settings where public key certificates may not be feasible due > >> to the incurred overhead, e.g. for when authenticating using EDHOC > >> (draft-ietf-lake-edhoc). > >> > >> This functionality is thus a subset of what is already supported, but > >> since the current solution is geared towards groups a different solution > >> may be needed (although it is probably possible to reuse parts from the > >> existing schemes for provisioning and requesting public keys). > >> > >> > >> > >> With this in mind, I propose the following change (highlighted in > >> boldface below): > >> > >> > >> > >> OLD > >> > >> The Working Group is charged with maintenance of the framework and > >> existing profiles thereof, and may undertake work to specify profiles of > >> the framework for additional secure communications protocols (that are not > >> necessarily limited to constrained endpoints, though the focus remains on > >> deployment ecosystems with a substantial portion of constrained devices). > >> > >> > >> > >> NEW > >> > >> The Working Group is charged with maintenance of the framework and > >> existing profiles thereof, and may undertake work to specify profiles of > >> the framework for additional secure communications protocols *and **for > >> additional **support services **providing* *authorized access to crypto* *keys > >> *(that are not necessarily limited to constrained endpoints, though the > >> focus remains on deployment ecosystems with a substantial portion of > >> constrained devices). > >> > >> > >> > >> Göran > >> > >> > >> > >> > >> > >> > >> > >> On 2020-10-15, 19:50, "Ace" <ace-bounces@ietf.org> wrote: > >> > >> Hi, > >> > >> I would like to start the charter discussion. Here is a draft of a > >> proposed charter [1]. > >> > >> > >> > >> It seems to be that additional discussion is needed with regard to the > >> last paragraph related certificate management. In particular the discussion > >> might revive a discussion that happened in 2017 [2] - when I was not > >> co-chair of ACE -and considered other expired work such as [3]. Please make > >> this discussion constructive on this thread. > >> > >> > >> > >> The fundamental question is whether we need certificate management at > >> this stage. If the answer is yes, and we have multiple proposals, it would > >> be good to clarify the position of the different proposals and evaluate > >> whether a selection is needed or not before validating the charter. > >> > >> > >> > >> Please provide your inputs on the mailing list before October 30. Of > >> course for minor edits, you may suggest them directly on the google doc. > >> > >> > >> > >> Yours, > >> > >> Daniel > >> > >> > >> > >> [1] > >> https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing > >> < > >> https://protect2.fireeye.com/v1/url?k=4f3d9c3b-118c475b-4f3ddca0-86e2237f51fb-627e48b069462d70&q=1&e=6924b2a6-e7e5-4ec1-a1af-c94637953dc5&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing> > >> > >> > >> [2] > >> https://datatracker.ietf.org/doc/minutes-interim-2017-ace-03-201710191300/ > >> > >> [3] https://datatracker.ietf.org/doc/draft-selander-ace-eals/ > >> > >> > >> > >> -- > >> > >> Daniel Migault > >> > >> > >> > >> Ericsson > >> > > > > > > -- > > Daniel Migault > > Ericsson > > > > > -- > Daniel Migault > Ericsson > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace
- [Ace] Charter discussion Daniel Migault
- Re: [Ace] Charter discussion Göran Selander
- Re: [Ace] Charter discussion Michael Richardson
- Re: [Ace] Charter discussion Göran Selander
- Re: [Ace] Charter discussion Panos Kampanakis (pkampana)
- Re: [Ace] Charter discussion Brockhaus, Hendrik
- Re: [Ace] Charter discussion Daniel Migault
- Re: [Ace] Charter discussion Göran Selander
- Re: [Ace] Charter discussion Daniel Migault
- Re: [Ace] Charter discussion Daniel Migault
- Re: [Ace] Charter discussion Daniel Migault
- Re: [Ace] Charter discussion Benjamin Kaduk
- [Ace] Proposed charter for ACE Daniel Migault
- [Ace] Proposed charter for ACE (EAP over CoAP?) Dan Garcia
- Re: [Ace] Proposed charter for ACE (EAP over CoAP… Daniel Migault
- Re: [Ace] [core] Proposed charter for ACE (EAP ov… Laurent Toutain
- Re: [Ace] [Emu] Proposed charter for ACE (EAP ove… Mohit Sethi M
- Re: [Ace] Charter discussion Daniel Migault
- Re: [Ace] [core] Proposed charter for ACE (EAP ov… Göran Selander
- Re: [Ace] Charter discussion Olaf Bergmann
- Re: [Ace] Charter discussion Daniel Migault
- Re: [Ace] Charter discussion Brockhaus, Hendrik
- Re: [Ace] Charter discussion Daniel Migault
- Re: [Ace] [core] Proposed charter for ACE (EAP ov… Michael Richardson
- Re: [Ace] Charter discussion Brockhaus, Hendrik
- Re: [Ace] [Emu] [core] Proposed charter for ACE (… Dan Garcia
- Re: [Ace] [core] Proposed charter for ACE (EAP ov… Dan Garcia
- Re: [Ace] [core] Proposed charter for ACE (EAP ov… Alexander Pelov
- Re: [Ace] Proposed charter for ACE (EAP over CoAP… Christian Amsüss
- Re: [Ace] [core] Proposed charter for ACE (EAP ov… Carsten Bormann
- Re: [Ace] [core] Proposed charter for ACE (EAP ov… Michael Richardson
- Re: [Ace] [core] Proposed charter for ACE (EAP ov… Dan Garcia
- Re: [Ace] Proposed charter for ACE (EAP over CoAP… Georgios PAPADOPOULOS
- Re: [Ace] [core] Proposed charter for ACE (EAP ov… Mališa Vučinić
- Re: [Ace] [core] Proposed charter for ACE (EAP ov… Dan Garcia Carrillo
- Re: [Ace] [core] Proposed charter for ACE (EAP ov… Mališa Vučinić
- Re: [Ace] [core] Proposed charter for ACE (EAP ov… Dan Garcia Carrillo
- Re: [Ace] [core] Proposed charter for ACE (EAP ov… Benjamin Kaduk
- Re: [Ace] [core] Proposed charter for ACE (EAP ov… Dan Garcia