On Thu, Aug 31, 2023 at 2:09 AM Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> 1) There may be a number of orthogonal properties, causing the total > number of possible profiles be very large (the CA-side code is > NOT complex). > I'm not super concerned with combinatorial explosions of profiles. A CA could offer many profiles that differ in small ways, but a) It would be their responsibility to ensure that all profiles abide by their PKI's requirements; and b) It would be their responsibility to clearly communicate what each of those profiles means to their subscribers. Honestly, doing both of those is difficult. So I think CAs will be incentivized to limit themselves to a small number of well-curated profiles, just like they limit themselves to a single profile today. > I think the server should reject the order creation if "profile" field > is present, but contains some unknown or disallowed value. The default > only appiles if there is no "profile" specified. > I considered this, because as you say it certainly makes sense to simply reject orders which request a non-existent profile. However, I think that it breaks down in practice: we know that there will be clients which are set up once, configured with a profile name once, and then never updated ever again. The CA needs the ability to evolve and deprecate profiles without causing those clients to permanently fail. Therefore I think it is best that the ACME server SHOULD reject such requests but MAY ignore the unrecognized profile and select a default instead, or something like that. > The reason why TLS 1.3 changed the algorithm negotiation to be more > pick-and-choose is because the TLS 1.2 way would have been completely > unworkable. > I was specifically referring to the combinatorial explosion of four-part cipher suites available in TLS 1.2, versus the much smaller list of two-part cipher suites available in TLS 1.3. Allowing clients to mix-and-match key exchange algorithms with bulk cipher and hashing algorithms led to significant problems. Aaron
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
