Hi Christian, 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.
Another profiles has also seen the need to provide information about the preferred profile of C. In Section 8 of the Group OSCORE profile of ACE, C uses the audience to indicate both who is affected and what profile that is requested, which gives more meaning to the audience than intended: https://datatracker.ietf.org/doc/html/draft-ietf-ace-group-oscore-profile-03#name-guidelines-on-using-multipl 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. 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. Göran From: Christian Amsüss <christ...@amsuess.com> Date: Wednesday, 4 December 2024 at 14:40 To: ace@ietf.org <ace@ietf.org> Subject: [Ace] Clarification on RFC9200: May client set ace_profile!=null? Hi, reading what RFC9200, it is not fully clear whether the client is allowed to set request a particular ACE profile (eg. by sending ace_profile=2), or whether the only choice the client has in that is whether or not to ask the AS to send which profile the AS picked (by sending ace_profile=null) in the C-AS message. The document talks a lot about the null value being allowed in requests (section 5.8.1. and 5.8.4.3.), but neither allows nor forbids regular values. This has led to some disagreement on [1], which I originally intended to clarify by filing an erratum -- but I wouldn't even know what to put in as proposed text. Note that with the profiles I currently know, there's not a lot of chance for ambiguity; for example, if a client supports both the ACE-OSCORE profile and the ACE-EDHOC-OSCORE profile, it will either send an almost empty token request (for OSCORE), or a token request with its own cnf set (for EDHOC), so the AS will have a good idea already, but that's basically just a furtunate coincidence; as more profiles get added, the space for requests that could be ambiguous grows. While in most cases it likely makes sense for the AS to decide the profile, I think it does make good sense for the client to pick one profile or the other in some cases (eg. depending on power available, expected connection duration or round-trip time), within what the AS considers acceptable. Is there text we missed in RFC9200 that would clarify this one way or the other, or is this indeed unclear, and then, what's the intended design? BR Christian [1]: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnamib-project%2Fdcaf-rs%2Fissues%2F28&data=05%7C02%7Cgoran.selander%40ericsson.com%7Cf194a72fcb33452ed31908dd146930e8%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638689164225826572%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=I3z3jnRdr4DMd5t%2BNIC6NrZtDRQ%2BbAKTDi4g3qag3SM%3D&reserved=0<https://github.com/namib-project/dcaf-rs/issues/28> -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
_______________________________________________ Ace mailing list -- ace@ietf.org To unsubscribe send an email to ace-le...@ietf.org
