Re: [Ace] [Emu] Proposed charter for ACE (EAP over CoAP?)

Mohit Sethi M <mohit.m.sethi@ericsson.com> Fri, 04 December 2020 10:26 UTC

Return-Path: <mohit.m.sethi@ericsson.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 C62753A0644; Fri, 4 Dec 2020 02:26:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.092
X-Spam-Level:
X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 DDRrCKVXLAwD; Fri, 4 Dec 2020 02:26:16 -0800 (PST)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2059.outbound.protection.outlook.com [40.107.22.59]) (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 CB1B73A05F8; Fri, 4 Dec 2020 02:26:15 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C+qOfSF/upKCjkbxg39VPgFuYuAowN06bgEw9YdUfLknlDodLz4SEAh56qrVhe+IjRHa2YBTdNslDVgBb411DKC2SN4IUgALsHehNLS1WJEXCcacSNABczNDoy8UMpNe8Rr2Sgq4Q+Cz/flcCXitb8Bi/96G4fVaMwftpd+8xymvLPy4FKtp7pT76yzVJQ5mh5Hbfsxvm9U0E+ZwgK3Jh+eVbkAXzD566Mnjy8hOhDGnTRJBKYdBuJsTz/mxPQv7mI9M/LYjbql3rtAiL1jJHPYYj/LaTzHwAewTkX6JBZUoE4LNlN0x08o1xS3qLAfovO/x6lBf4n5IqlUB2PbHvw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RETc61wXAjt316TIoLTo8Gs4JSRrcq7x05+6/wh+ews=; b=XSrmnBWEUJUlL+YN3twvnvhaYxyrNDu/x2IkOK3qN6Je8uBWdcxZFDUcjtZN0pbeMP5L751TJdFlX5IWJrobIvyJYmvDwbpg4c9EewO/Z2bXLvMENdiUk9XDFUoNcKvxakoDvxIhyS3A4CqwLspXigTObnvRhA56ok0dlHVc4MP1YvOKY8H8vLQIuNlgIx1QjyEbSu3lolfDoq7PF6ceBx2kUPhxiLltkQwYLjN54Owwlw/Bdh3TBkwzBRX/no4jbycHl//JitTJkby1TfGHkPAKSF5nRM3BDdG48PcZSRFOMqGkQXb7sh6ebYvFq5cFEY3uBLSsQG6AAmAAlo3QrA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RETc61wXAjt316TIoLTo8Gs4JSRrcq7x05+6/wh+ews=; b=bP+9jQXQ6dHIxHkyzzhSyL5vCUKzuYTmYmsqTAxw1lepFYuasq93FpEGw/LuUDSL7doKJ5u8Si/tv/0hhDpVgNWKnrUm57fzr5aD4wEje3047XJPTfHhBIW7rvVsfzK1Hn4HPU9T3rhzWtKD/IdHVUx2pChipQpiD/9PUVfXrEc=
Received: from HE1PR0701MB2185.eurprd07.prod.outlook.com (2603:10a6:3:2a::21) by HE1PR07MB4201.eurprd07.prod.outlook.com (2603:10a6:7:98::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.15; Fri, 4 Dec 2020 10:26:13 +0000
Received: from HE1PR0701MB2185.eurprd07.prod.outlook.com ([fe80::9923:403e:592f:d8eb]) by HE1PR0701MB2185.eurprd07.prod.outlook.com ([fe80::9923:403e:592f:d8eb%10]) with mapi id 15.20.3654.009; Fri, 4 Dec 2020 10:26:13 +0000
From: Mohit Sethi M <mohit.m.sethi@ericsson.com>
To: Daniel Migault <daniel.migault=40ericsson.com@dmarc.ietf.org>, Dan Garcia <dan.garcia@um.es>, "ace@ietf.org" <ace@ietf.org>
CC: EMU WG <emu@ietf.org>, "core@ietf.org WG (core@ietf.org)" <core@ietf.org>
Thread-Topic: [Emu] [Ace] Proposed charter for ACE (EAP over CoAP?)
Thread-Index: AQHWyifjYCmuD4WkfEaX3bQfrc+gxA==
Date: Fri, 4 Dec 2020 10:26:12 +0000
Message-ID: <037f8fae-e663-0f68-01db-f8c36e0fe25f@ericsson.com>
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> <20201117234700.GR39170@kduck.mit.edu> <CADZyTknej3DUbbKbRxdfi0HqVR7G7qkAh5htu3w9yFjE09sOtg@mail.gmail.com> <b78c1176-ffa0-9ad5-847e-94e9134b4212@um.es> <DM6PR15MB2379308BD779061F6F46233EE3F20@DM6PR15MB2379.namprd15.prod.outlook.com>
In-Reply-To: <DM6PR15MB2379308BD779061F6F46233EE3F20@DM6PR15MB2379.namprd15.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [2001:14bb:1a3:54b1::1a4f:ee01]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7fcba3ba-9f85-4982-deaa-08d8983f066a
x-ms-traffictypediagnostic: HE1PR07MB4201:
x-microsoft-antispam-prvs: <HE1PR07MB4201C60551F51DBB6BD2A3CBD0F10@HE1PR07MB4201.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: xiH6eRudVw5oma/KtbbmGLmnprfWwWEQuURmNjVcpiagQBA+l07kh+xvkUoHH1kI60ho4J1+HnzLPu8a0zjjOCYMOaJpwT2O6QNYsbpahSeRYapIARGTsnPfK9+ggzDOyL/C1nd5Ob1+1ppdeBmpbZHMnW68dWwGEXjHNFwGvSYuzf7jRkb1IX+6+uLFi79GFNOILVI7+a584R6rgs0TeBHe9Yqwpb2OenANZDSBOAVRd5Dfi3llZhiiFG0t0MQQwFfqysci0eANRtolmeP+CmU0XGXFyO/XDkKmz3ccv5vu1q+3RXdzXgglSUgu1h1ooy6c/dGQZL4T9Q7UZl1knHzhG8sgG+7ymVeTPHZ/zps4YBc4Aj3aYH+LEhYepQJUUl8oA7p7fZQfteEF8HheLUiBAh3xpwZk8+hEfne5Mnm9pvCDDm/IxUDcfYWDkmoSIyz2fQS4JzmAysDaZZ7oLzd6mToIBWoyS2fpQvLMkjU=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB2185.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(39860400002)(376002)(366004)(136003)(110136005)(31686004)(8936002)(966005)(54906003)(71200400001)(66446008)(66476007)(5660300002)(66556008)(36756003)(76116006)(478600001)(19627405001)(316002)(30864003)(6512007)(66574015)(31696002)(66946007)(6486002)(83380400001)(166002)(53546011)(4326008)(2906002)(6506007)(64756008)(4001150100001)(86362001)(8676002)(2616005)(186003)(45980500001)(43740500002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?TqE9N0aZZj1D10xRPza2FEBDXzdyuqWR8i3cAwyAyNp+T07JSVCcOUTa?= =?Windows-1252?Q?Nv2cbs4UvxBlVhsEmajFMypm6crJrQV8aYguBhPDAlremvHdljlH7lJK?= =?Windows-1252?Q?jDEjeXsW8D4SpJJ//s2uX+LJyWj8sFlEc6gFhZpebzmob6QWAcSgikVp?= =?Windows-1252?Q?m+TkAWxhtpq9pdWYnrHfn1XXrc5Yv3XLNHVUQSQ62db4RWolW99pZedY?= =?Windows-1252?Q?837PzfWhuUzTmlNCIkQqOBuJ70haxGCYQi0VYlr4KiZmzAcuXjZ8MKcB?= =?Windows-1252?Q?wtBK5BnB7OXWbkjPmd3W6uQqU2pbEhRT+kUPRE8uiv82AIYQiidEy1zj?= =?Windows-1252?Q?NoKmyNKeqX+nvNrgbYaTmElb+BDS8+D1hDSK6JAbfxhNMqbGcbD9NYX6?= =?Windows-1252?Q?5e3RQjzawMXGYvf0qjGPzFmLa3GlM1dLyiBBIYAGCXImLWo84hOYbEDf?= =?Windows-1252?Q?M1h1e7GEM5Twkhdwt260n8k4MeVElJIFf0E6cggHqzl0wAKlvVaoynaC?= =?Windows-1252?Q?AnOJwim6WvW8L7byw403WMFJL9salYnLPzZcSsbnBG71PSe2UESXVlb2?= =?Windows-1252?Q?ZbKvaH72PjF2acI6x4bzqauR8nHZz1St8S5OAmgTo6aj8m7I5RAV7Phz?= =?Windows-1252?Q?zqCEsGOCNtSSFIGkZjTOPo1TItuXUvP4Y5XocfqVun02FDfgIGqLV/mx?= =?Windows-1252?Q?PvbY7MUwIv6ltqKJDjZY5En/WMnNN3roBU36scBER8fwUBK2xFtYPXD+?= =?Windows-1252?Q?UKIp++WDgQb9R8BvFAkuZjPOuWSNePyc+UhokTQAP30ClLw5U7LYRaAI?= =?Windows-1252?Q?jnfBFRd/+ad1EQp5P/lvaRmrGPuc+eZIBfADaXljakmoezqUnNZwxeyU?= =?Windows-1252?Q?bVLaaqWsVSyUs4iGDF5NspGCC6YMMsUpqoIo/6gza3nzuR6dssVFMW3e?= =?Windows-1252?Q?NTybb91wUKDSKU8IfhbP/8wzSIfM81YBJ/UfK+okqttpKG6LZPzhWkRb?= =?Windows-1252?Q?X5vEVxMjpnsnCmoaLsMmV90cvRPbXwpJ+FtUX6xjcDXcDoJRnDGhvEdc?= =?Windows-1252?Q?3nY5hMQdFjaXAzEWmYSh47zIPfzUxWCL+Pv2xg=3D=3D?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_037f8faee6630f6801dbf8c36e0fe25fericssoncom_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB2185.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7fcba3ba-9f85-4982-deaa-08d8983f066a
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2020 10:26:13.0064 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 7PFpGZqROF5oBOLsrCCGP0BkWcbgKOkqsJxdI+eHtz83PkX/cFz/IlDAtLAQa+SbPszLZ3yr7ewgleANhf9BHDR7wDE5l/Ltn+AO7uU4TOg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4201
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/zXyHAELWVtc9Ir_X8EBDCLlDmbI>
Subject: Re: [Ace] [Emu] Proposed charter for ACE (EAP over CoAP?)
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: Fri, 04 Dec 2020 10:26:20 -0000

Hi ACE,

I guess EMU is happy to see new deployments and uses of EAP. I think ACE is better suited for taking on this work if there is interest. EMU primarily deals with the base EAP protocol and various EAP authentication methods. We can obviously help with reviewing the document later on.

I would note that EAP-over-foo is generally defined by the lower-layer. So for example, EAP over LAN (EAPOL) is specified by IEEE. In this case, the lower-layer is CoAP so we at the IETF are responsible for specifying it (if there is a desire to do so). A draft for HTTP authentication with EAP was submitted a couple of decades ago: https://tools.ietf.org/html/draft-torvinen-http-eap-01. That was unfortunately never finished. But maybe CoAP will be different and ACE can finish this work item if it chooses to adopt it.


--Mohit

On 12/3/20 3:20 PM, Daniel Migault wrote:
CCing emu, core

It seems ACE to me that ACE could be home for such a document. I am wondering if emu core or any other WG believe there is a better place for it.

Regarding ACE I am wondering what is the WG opinion about adding this item to the ACE charter.

Yours,
Daniel
________________________________
From: Ace <ace-bounces@ietf.org><mailto:ace-bounces@ietf.org> on behalf of Dan Garcia <dan.garcia@um.es><mailto:dan.garcia@um.es>
Sent: Thursday, December 3, 2020 6:10 AM
To: ace@ietf.org<mailto:ace@ietf.org> <ace@ietf.org><mailto:ace@ietf.org>
Subject: [Ace] Proposed charter for ACE (EAP over CoAP?)


Dear all:

Regarding the new charter, since ACE is considering the definition of CoAP transport for CMPv2 (https://tools.ietf.org/html/draft-msahni-ace-cmpv2-coap-transport-00), we were wondering whethere it could also consider specifying EAP (Extensible Authentication Protocol) over CoAP.

In this sense, we proposed this some time ago and we have implementations about this.

https://datatracker.ietf.org/doc/html/draft-marin-ace-wg-coap-eap-06
https://www.mdpi.com/1424-8220/16/3/358
https://www.mdpi.com/1424-8220/17/11/2646

The usage of CoAP can provide a very light and link-layer independent (we even tested in LoRa networks) EAP lower-layer (transport for EAP) suitable for IoT enviroment. We believe this would be really useful since EAP provides flexibility for the authentication and it is a well-known protocol.

Therefore, we would like to propose the following modification to the charter:

"The Working Group will examine how to use Constrained Application Protocol (CoAP) as a transport medium for certificate enrollment protocols, such as EST and CMPv2, as well as a transport for authentication protocols such as EAP, and standardize them as needed."

This modification does not necessarily mean the adoption of our draft. After all, we completely understand that this would happen only if there is an interest in the WG. Nevertheless, we would like to avoid that the charter is a barrier later if there is interest in the WG to work in this transport of EAP over CoAP:

Any opinion about this?

Best Regards.

El 18/11/2020 a las 8:08, Daniel Migault escribió:
Hi,

Please find the proposed charter we agreed on during the interim meeting. If you would like to propose any change, please use the following URL by November 25:

https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing<https://protect2.fireeye.com/v1/url?k=f9dc6551-a6475d83-f9dc25ca-866132fe445e-9c25a5c257a23470&q=1&e=03ce3af5-6990-40e0-b2b5-255ac5f5dfe0&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>

Yours,
Daniel


The Authentication and Authorization for Constrained Environments (ace) WG has defined a standardized solution framework for authentication and authorization to enable authorized access to resources identified by a URI and hosted on a resource server in constrained environments.

The access to the resource is mediated by an authorization server, which is not considered to be constrained.


Profiles of this framework for application to security protocols commonly used in constrained environments, including CoAP+DTLS and CoAP+OSCORE, have also been standardized.  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 in ecosystems with a substantial portion of constrained devices).


In addition to the ongoing maintenance work, the Working Group will extend the framework as needed for applicability to group communications, with initial focus on (D)TLS and (Group) OSCORE as the underlying group communication security protocols. The Working Group will standardize procedures for requesting and distributing group keying material using the ACE framework as well as appropriated management interfaces.


The Working Group will standardize a format for expressing authorization information for a given authenticated principal as received from an authorization manager.


The Working Group will examine how to use Constrained Application Protocol (CoAP) as a transport medium for certificate enrollment protocols, such as EST and CMPv2, and standardize as needed.


On Tue, Nov 17, 2020 at 6:47 PM Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>> wrote:
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<https://protect2.fireeye.com/v1/url?k=a01e017d-ff8539af-a01e41e6-866132fe445e-7268e18ca0e30ad7&q=1&e=03ce3af5-6990-40e0-b2b5-255ac5f5dfe0&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>
>
> On Tue, Nov 17, 2020 at 6:02 PM Daniel Migault <mglt.ietf@gmail.com<mailto: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<mailto: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<mailto: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=2eaaeb96-7131d344-2eaaab0d-866132fe445e-7e515f25c81762b8&q=1&e=03ce3af5-6990-40e0-b2b5-255ac5f5dfe0&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>
> >> <
> >> 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<mailto:Ace@ietf.org>
> https://www.ietf.org/mailman/listinfo/ace

_______________________________________________
Ace mailing list
Ace@ietf.org<mailto:Ace@ietf.org>
https://www.ietf.org/mailman/listinfo/ace


--
Daniel Migault
Ericsson



_______________________________________________
Ace mailing list
Ace@ietf.org<mailto:Ace@ietf.org>
https://www.ietf.org/mailman/listinfo/ace




_______________________________________________
Emu mailing list
Emu@ietf.org<mailto:Emu@ietf.org>
https://www.ietf.org/mailman/listinfo/emu