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 <[email protected]> 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 < > [email protected]> 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" <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/ace
