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