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" <goran.selan...@ericsson.com> 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" <christ...@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
