Re: [Ace] OSCORE Profile status update and way forward

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 <christian@amsuess.com>
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
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>

-- 
Daniel Migault
Ericsson