Hi Christian, Inline.
On 2024-12-09, 12:33, "Christian Amsüss" <christ...@amsuess.com> wrote: Hi Göran! On Mon, Dec 09, 2024 at 10:46:06AM +0000, Göran Selander wrote: > Good questions. As I recall, the mindset for this was that the AS > should have the necessary information about the capability of RS and > the intended use of the resources, to decide which profile to use. > This also simplified the protocol, where the only alternative given > was that the AS needed to be explicit about the decision if > ace_profile = null in the request. But perhaps this was too simple. That sounds like a "should" (but the grammar allows otherwise because there are cases when one would do otherwise)? GS: If ace_profile in request equals null/empty, then MUST ace_profile with non-null value in response. If no ace_profile in request then MAY ace_profile in response. > If we want to consider Client profile preferences in the ace_profile, > we need to handle potential contradiction with AS (incl. RS) > preferences, and the associated complication of the protocol - we may > run into some sort of negotiation. There's no "if" there. We *already* have to consider what happens if the client disagrees with the server, for example when the AS expects that C and RS would talk ACE-EDHOC-OSCORE profile, but the client didn't send and PoP a key for it. > As I understand, we can handle the current situation (although perhaps > not in a structured and extensible way). If this is something we want > to solve in a more structured way? If so, what is the desired > behaviour between C and AS? > > 1. C proposes one profile, AS accepts/rejects (with error > incompatible_ace_profiles) > 2. C lists profiles in order of preference. AS selects the first in policy or > else rejects (with error incompatible_ace_profiles) > 3. ? > > Compatibility with the semantics of the null value must also be ensured. I think 1 is what we practically have already: The AS may reject it (like in the case above). The only unclear point is whether C can be explicit in its expectation by sending a non-null value. The semantics of the null value are unharmed by that. There might be a case for 2, but I don't have it; I'd guess that sensible semantics are as you describe, with the addition that whenever a list is offered, the response would be explicit. In short, this sounds to me as if 9200 was ambiguous, the intention was to not allow profile values in requests, but there's no harm in allowing it in an erratum (given that it was not explicitly stated as forbidden). GS: I agree with the gist of the last part of the sentence but I don’t think that characterizes “ambiguous”, it is rather “unspecified” or “extensible” 😊. GS: So, it seems case 1 could be a useful update. That would also be applicable to draft-ietf-ace-group-oscore-profile. But I don’t see this as an erratum, seems more like a short draft to me. Göran
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Ace mailing list -- ace@ietf.org To unsubscribe send an email to ace-le...@ietf.org
