Hi all! I’d like to add two ideas:
1. The profile entries in the new Profiles object should be capable to link to ACME servers on a different URL. By this, one could maintain a central list of ACME servers operated by various CAs within the ACME protocol standards. 2. We should enforce, that every profile object must contain a URL to the CP/CPS of the respective CA (or to the CCADB entry). Thank you very much for this proposal to extend ACME! /Rufus Von: Acme <[email protected]> im Auftrag von Aaron Gable <[email protected]> Datum: Donnerstag, 31. August 2023 um 00:21 An: IETF ACME <[email protected]> Betreff: [Acme] Proposal: ACME Profiles Hi ACME community, 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. Historically, profile selection within ACME has been somewhat ad-hoc: · The NewOrder request contains “notBefore” and “notAfter” fields which allow clients to request certain validity periods, but other aspects of the certificate cannot be customized and support for these fields is minimal. Let’s Encrypt rejects requests which contain these fields, and Google Trust Services recommends that they be omitted, because clients are likely to request values which the server cannot respect (e.g. notBefore dates unacceptably far in the past, violating BRs requirements regarding backdating). · The CSR contained in the Finalize request message can carry additional information, but copying values directly from CSRs to final certificates has been the root cause of many CA incidents, so great care must be taken. Let’s Encrypt does use the presence of the “ocspMustStaple” extension in the CSR to cause the inclusion of the same extension in the final certificate, but this is the only attribute we extract from the CSR and frankly we’d rather not even do that much. · I’m aware of one CA which uses url query parameters to control aspects of the certificate profile. The client specifies query parameters in its configured directory URL, the directory object reflects those same parameters back in its newOrder URL, and then the newOrder endpoint processes those query parameters to affect the certificate profile. Recently there has been an uptick in interest in profile selection in ACME. For example, the recent PQC negotiation thread<https://mailarchive.ietf.org/arch/msg/acme/FEZYTUfhSeur-wKQI6H2xytSkvY/> is largely an exercise in profile selection. There’s also been significant discussion<https://community.letsencrypt.org/t/offer-a-new-endpoint-and-acme-spec-update-to-list-available-chains/203329> on the Let’s Encrypt community forum, largely prompted by the desire for more control in intermediate selection. Let’s Encrypt itself is interested in formalizing profile selection so that we can make backwards-incompatible changes to our current issuance profile without breaking clients. And of course I’ve spoken with other CAs who are interested in the same. 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). 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. 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. 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. Therefore I believe that this simple approach is best. It will be easy for both clients and servers to adopt. It will allow CAs to offer well-vetted profiles for clients who need specific attributes. And it will allow CAs to preview upcoming profile changes to clients that want to opt in and to gracefully evolve profiles over time. We are already working on a draft which formalizes the proposal above, and hope to implement a version of this in the near future to facilitate the evolution of our own issuance profile. We’d love to hear all of your thoughts before we embark down this path! Thanks, Aaron
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
