Re: [Ace] Charter discussion

[Daniel Migault <[e-mail]>]

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


-- 
Daniel Migault
Ericsson