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