On Wed, Aug 30, 2023 at 03:21:30PM -0700, Aaron Gable wrote: > > I believe it is time for us to seriously consider the topic of “profiles”. > > For the purposes of this discussion, a profile is a collection of > characteristics which affect the contents of the final certificate issued > by an ACME CA. For example, two different profiles might cause certificates > to have different validity periods (e.g. 10 days vs 90 days), or different > EKUs (e.g. ServerAuth and ClientAuth vs ServerAuth only), or even be issued > from different intermediates. > > Therefore I believe it is time for ACME to grow support for some form of > profile selection. As argued above, I don’t think that the Finalize CSR is > a good format for this, so something will need to be added to the ACME > protocol itself. I propose the following very simple change: > > 1. The directory’s meta object gains a new “profiles” sub-object, whose > keys are short profile name strings (such as “default” or “rsa 2023”) and > whose values are human-readable descriptions of those profiles (such as > “our standard profile, but with a validity period of only 10 days” or a URL > pointing at more verbose documentation).
I think there are cases, where the list of profiles in directory can not be exhaustive. 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). 2) There may be profiles that are either not allowed (e.g., EV only), or do not make sense (e.g., compatibility hacks) for most certificates. What is needed to support these cases is for ACME client to allow configuring profile without any client-side checks. Or more extreme way would be to just have the "profiles" be a string pointing to CA documentation. That would preclude ACME clients doing any validity checks. > 2. The Order object gains a new “profile” field, which can be set in > NewOrder requests, or will be set automatically by the Server according to > its own server policy if no recognized profile is requested. 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. Then there is edge case of where key types are restricted by profile and client tries to do something disallowed (e.g., DC certificate with RSA key). However, bad key errors already happen at finalize time (and autofinalize is a separate topic). > In some of the discussions mentioned above, much more complex systems have > been proposed. These systems would establish a format for a CA to advertise > every individual adjustable field and all values each field can take. > Clients would then have the ability to both tightly customize the > certificate they request, and to compare the offerings of multiple CAs to > select the one that most closely matches their operator’s preferences. > However, I believe that such a complex system would ultimately be largely a > failure, as most operators would not have complex desires to express, most > clients would not implement complex configuration mechanisms to allow > operators to do so, most CAs would not advertise directly-comparable sets > of attributes, and if we attempted to standardize the set of advertisable > attributes we would inevitably fail to anticipate actual needs. Yeah, such thing would be a bad idea, as the complexity is at best extreme, and likely unsurmountable. Best to have admin manually configure the profile (since CAs already need manual configuration). > Additionally, we’ve seen from TLS algorithm negotiation itself that it is > better to offer a few well-studied options than to allow (poorly configured > or misinformed) clients to pick-and-choose from a wide variety of options. I think it is the exact opposite. 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. And having implemented both (with very little confidence on correctness of TLS 1.2 one), the TLS 1.3 one is much simpler to implement. -Ilari _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
