I am not hearing anyone opposing the proposed way to move forward. Once we will have the update from Francesca, we will be able to start a WGLC. On the other hand, we will need reviews to move the document forward, so please remain committed for the last miles!
Yours, Daniel On Mon, Oct 19, 2020 at 4:45 PM Daniel Migault <[email protected]> wrote: > Thanks Francesca for the reply. Other members of the WG, if you have an > opinion, please let the WG know asap. We set October 20 to get comments on > which path to take. > > Yours, > Daniel > > On Mon, Oct 19, 2020 at 11:52 AM Francesca Palombini <francesca.palombini= > [email protected]> wrote: > >> Hi Christian, Daniel, >> >> Daniel: I agree that what you describe is the best way forward. Once the >> PR regarding the negotiation of Ids is merged, I can only see a minor >> addition to the draft, to clarify what Christian has brought up. By the end >> of this week we should have Christian's comment implemented as well. After >> that, we're ready for another round of reviews, and I think a WGLC is >> warranted. >> >> Christian, let us know if there is anything else except some more >> considerations covering what you are saying. Göran summarized it well, but >> basically no, there is no particular benefit. The sentence was added as the >> response from a review comment, but it seems like a good idea to add more >> context to it. >> >> Thanks, >> Francesca >> >> On 15/10/2020, 20:01, "Göran Selander" <[email protected]> >> wrote: >> >> Hi Christian, >> >> The purpose of the update was to clarify that Appendix B.2 of RFC >> 8613 could be used in conjunction with the ACE OSCORE profile. But as you >> point out, the use of B.2 would need to be understood between the client >> and server beforehand. There are slight differences: With B.2 there is no >> need to transport the access token again. And B.2 can be triggered by the >> (resource) server, if it understands that it does not have the right >> context (which can happen even if there is no ID context in the request). >> Just using the ACE OSCORE profile, the client would need to understand that >> the context is lost and run the protocol again. So, there is a difference >> but essentially the same functionality can be obtained. >> >> Would it be sufficient to clarify the differences as above to address >> your comment? >> >> Thanks, >> Göran >> >> >> On 2020-10-09, 17:45, "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
