[Acme] Proposal: ACME Profiles

[Aaron Gable <[e-mail]>]

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