Hi, To follow-up this thread, we discussed with Ben and found out that the best path would be to go through an official WGLC before sending the document back to the IESG. This should not change much as a careful review of the document was needed anyway (C), so the WGLC would just consist of these reviewers to confirm their reviews.
Yours, Daniel On Tue, Oct 13, 2020 at 9:10 AM Daniel Migault <[email protected]> wrote: > Dear WG, > > If I attempt to balance the different 3 proposals, my perception is we may > address a specific scenario into the core profile with no additional > complexity versus via extensions. This leaves working on a profile v2 > (option 2) or updating the to-become soon profile v1 (option 3). I prefer > to avoid specifications being deprecated before they are even published and > would prefer to consider updating the current version. > > I suspect that multiple versions of a profile can co-exist and that the > problem of having a profile v2 that interoperate with a profile v1 - which > does not seem mandatory. > > In order to move forward, I propose that by October 20: > * A) WG member state their opinion regarding that we revise the oscore > profile document > * B) Francesca refines the proposed changes, so the document is ready for > review > * C) WG member state whether they volunteer to review the updated > document. I would like to avoid the document re-opened once considered > updated. > > With A, B and C I will be able to discuss with Ben how to move forward the > document. I am happy to get your feed backs or suggestions. > > Yours, > Daniel > > > > > > On Fri, Oct 9, 2020 at 11:45 AM Christian Amsüss <[email protected]> > wrote: > >> Hello Francesca, hello ACE group, >> >> On Mon, Sep 21, 2020 at 01:48:33PM +0000, Francesca Palombini wrote: >> > - clarified that Appendix B.2 of OSCORE can be used with this profile, >> > and what implementers need to think about if they do. >> >> I understand B.2 to be something that the involved parties need to agree >> on beforehand; after all, the ID context may be something the server >> relies on (at least for the initial attempt) to find the right key, >> especially when multiple AS are involved. (For example, the RS could >> have an agreement that the AS may issue any KID as long as they use a >> particular ID context). If the server expects B.2 to happen (which, as >> it is put now, it can as long as it supports it in general), it needs to >> shard its KID space for the ASs it uses. (Generally, B.2 is mutually >> exclusive with ID contexts's use of namespacing KIDs). >> >> Is the expectation that clients that do not anticipate B.2 by the time >> they are configured with their AS just don't offer B.2 to their peers? >> >> Given B.2 is in its current form client-initiated only (AFAIR we had >> versions where ID1 could be empty in draft versions, but currently it >> reads as client-initialized), does B.2 have any benefits for ACE-OSCORE >> clients? After all, they could just as well post the token with a new >> nonce1 to the same effect. >> >> Kind Regards >> Christian >> >> -- >> To use raw power is to make yourself infinitely vulnerable to greater >> powers. >> -- Bene Gesserit axiom >> _______________________________________________ >> Ace mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ace >> > > > -- > Daniel Migault > Ericsson > -- Daniel Migault Ericsson
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
