Re: [Ace] Charter discussion

[Göran Selander <[e-mail]>]

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" <[e-mail]> 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