Re: [Ace] Charter discussion

Daniel Migault <mglt.ietf@gmail.com> Tue, 17 November 2020 23:17 UTC

Return-Path: <mglt.ietf@gmail.com>
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 2A0533A0F35 for <ace@ietfa.amsl.com>; Tue, 17 Nov 2020 15:17:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 rqQ6MOYv2RkF for <ace@ietfa.amsl.com>; Tue, 17 Nov 2020 15:17:01 -0800 (PST)
Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E13C03A0F41 for <ace@ietf.org>; Tue, 17 Nov 2020 15:17:00 -0800 (PST)
Received: by mail-ua1-x92c.google.com with SMTP id p12so58959uam.1 for <ace@ietf.org>; Tue, 17 Nov 2020 15:17:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=axNbNF6/hm0hAnaFxI7tl0PyqD0lE4ZQY2P+2Dz9nUY=; b=swiJnC6LDFIKAJVRdusGYBxyrM+OitL5UH41H7tcl4pk9o0+j0uv4N1vCLStRM4p24 2FAx+XL3JPsXAX0zEXA/G4jD18KQ6Y5mTG/WcnqVo7QFcJCmfyWk6S9N/PpZlOVUViw3 bJuR81XQJzLigKvkNaIuRsMUjW6f0tO0CZxultakZ4q0Gyxv1L9oN+ZfsA38tc2PbnD6 +pihb2QgqpTqTs0DDHtN0UCAof00uneLHNkQYXccCgy1aL2elc934lJjvT6iw0bsyCHN 7wTbrTxhnP0XdTt5x3026uu+mnp/WGrYQRqDk8jFQMSZGbRDnroQ+GmaCkkGqt0iqmKA MTVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=axNbNF6/hm0hAnaFxI7tl0PyqD0lE4ZQY2P+2Dz9nUY=; b=THZ2xFrrKnR9VuoQMf/iEXIdObpbdQmF+6Rt6vk3rB/JS6q5OFyvY2vXAhyPpbdCEg j17DMeUietFC/fvDR/odzmFif2x8rUp5ZtTnRL1ISbmdJD6jWwsUylyps/3YyxNHBssi BmoFGEhVs79zEWa4APDifp3/PXu09RIpVvuNl0jAwvaN6SQk1by9CdydcH75lOs3Q3bT Gw/scs4IDw3B42FbxI+LPEEUAzwIwsXP952cNTDgz87vEkuZ/PNt0rkJ6smg8iczP7gN crP2XR//4BB7wAhJ/l+8G5GeVNVip/Kl2Lv5QBNQat3Ab6tsFguhk27Pvmj+v8mtr7h2 DrkQ==
X-Gm-Message-State: AOAM530XuNM0veW3dCY9I/pSUdbc9bm8GKKCRcFc1gJ9qiUJHRniWwQP Fbz6qe9S1JR8aw7OhJ1cSK+Pa2KKLMK36jePPTVSEl2CSMTLfrkh
X-Google-Smtp-Source: ABdhPJwdEgePnwcLJTeb10Lc6mdnbCtvYugmjTVezk0fpOa6TGOhnHKPmcKpp7GXJglCnFOuUSq7HvFsza8yuekoERo=
X-Received: by 2002:ab0:5a10:: with SMTP id l16mr1656991uad.0.1605655019895; Tue, 17 Nov 2020 15:16:59 -0800 (PST)
MIME-Version: 1.0
References: <CADZyTkmnV_Dhb5iXzykUyEAskLDg7tj=80CbEBGmSyFQNS2FHw@mail.gmail.com> <HE1PR0702MB36740BAAFD7FDA2688564BF7F4E60@HE1PR0702MB3674.eurprd07.prod.outlook.com> <CADZyTkkpLRvqD5Vx704u=qbRvE82o4cKk3Ff2Y2ZXes_B+nRbA@mail.gmail.com>
In-Reply-To: <CADZyTkkpLRvqD5Vx704u=qbRvE82o4cKk3Ff2Y2ZXes_B+nRbA@mail.gmail.com>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Tue, 17 Nov 2020 18:16:48 -0500
Message-ID: <CADZyTkkSGiUvXf0NoVUwj0Vjf7AQ=pjdEHyHZsDdE67OvfTepw@mail.gmail.com>
To: =?UTF-8?Q?G=C3=B6ran_Selander?= <goran.selander@ericsson.com>
Cc: Ace Wg <ace@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000017be8805b455b1ae"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/WOvltLWTsU2NYrvtkaRtUbZtdjE>
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:17:03 -0000

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