Proposal: ACME Profiles

[aarongable]

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 chain selection thread led to a long discussion on profile selection as well. There's also been a PQC negotiation proposal on the ACME mailing list which is largely an exercise in profile 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

P.S. This message has also been posted to the IETF ACME mailing list here.

[orangepizza]

Some split feeling about this:
unlike TLS algos for certificates not all combination of parameters are valid to be signed just because each oid in it valid: (like 10-day and must-staple unlikely to be accepted even if both are 100% valid parameters) so even when list of parameter is opened it's likely server have to reply 'nope, that combination is invalid'.

but even with 8 parameters we will have few hundreds of profiles ,which is why TLS 1.3 moved to per parameter config but ultimately its CA who sets the profiles so they will keep the list short.

[aarongable]

Yep, the fact that certain combinations of attributes are unacceptable is definitely one of the concerns leading me towards this more monolithic approach.

The potential combinatorial explosion of profiles is also a concern, but as you say, today the CA has to decide what one profile to offer -- I don't think it's too much to ask for them to make a conscious and informed decision about what two or three profiles to offer.

For example, we're currently thinking that we'll offer just two: the current profile, and a "modern" profile that includes many small changes. Maybe there will be a third, if we decide to make short-lived certs a separate profile instead of baking that into the modern profile. Eventually, the modern profile will become the default, but hopefully lots of people will have opted in to it before then.

[jvanasco]

@aarongable

For example, the recent chain selection thread led to a long discussion on profile selection as well. There's

I would like to clarify the discussion in that thread was not about Chain Selection, but instead about a Server communicating to Clients the Available Chains / Roots before making any expensive or metered requests in the ACME Order process -- instead of in the last step of the ACME protocol.

That being said, I fully support the Profiles concept that @aarongable has been advocating. It elegantly solves the forthcoming issue of a single ACME Server providing both "Standard" and "Short" lifetime certificates in addition to several other concerns.

[orangepizza]

with profiles will they include must-staple-or not version? or profile will just say "this oid will be lifted from CSR"? I guess profiles should list what parameters will be 'copied' form CSR,

[Nummer378]

@orangepizza

with profiles will they include must-staple-or not version?

I don't see why they should. ACME has previously handled this via CSR so its easiest to leave it this way.

@orangepizza

or profile will just say "this oid will be lifted from CSR"? I guess profiles should list what parameters will be 'copied' form CSR

As currently proposed, the CA can set a human-readable description for each profile which may contain this information, if the CA desires this. However, I don't think its reasonable to encode this information in a machine-readable way.

If a CA doesn't like a CSR in combination with the given profile (e.g. your example "no OCSP available because short-lived cert, but must-staple requested in CSR"), the CA can just reject the CSR with a "badCSR" error. This is already how it's handled today: If you include things in a CSR the CA doesn't like, it will simply require the ACME client to (re-)submit a different CSR. With profiles, this behaviour could remain as-is.

[rg305]

@aarongable

opted in

What about those clients that want to "opt out"?
OR
Those that are very slow to update/adapt [like: those that are no longer actively maintained]?

In other words: Will this ever become a requirement for all ACME clients?

[rmbolger]

@rg305

In other words: Will this ever become a requirement for all ACME clients?

@aarongable

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 "will be set automatically" portion of this covers the clients that can't or won't be updated. Essentially, there will continue to be a "default" profile that gets set if not overridden by this profile field.

[saudiqbal]

Does it mean I can request the shortest X2 only chain without being on the special opt-in list? Right now I have to upload the full account directory to every new instance I create to get the ECDSA only cert.

[9peppe]

It probably means you can ask for a full ECDSA chain, whether that uses E1 or another intermediate from X2 or another future root, that's the good thing about profiles: you could pin chain or certificate properties without pinning intermediate or root private keys. (That might not work that well with DANE, though, but I expect future roots to be cross signed by current roots)

[Nummer378]

Chain selection has recently been discussed in this thread: Offer a new endpoint (and ACME spec update) to list available chains

As I understand this proposal, it will not directly affect chains. Whether you're getting the RX or EX chain depends on the key type you submit. The profile doesn't affect this. Remember that the allowlist for ECDSA will eventually be removed. Profiles don't sound like a drop-in replacement for it.

In the future, the profile could avoid having to allowlist more features. For example, instead of having accounts allow-listed for "reduced set of EKU", this can be controlled via the proposed "modern" vs "legacy" profile.

I can imagine scenarios where the profile does affect chains (e.g. there's a new hierarchy with completely different compatibility not selectable by key type). But in the general case, the profile shouldn't affect key types IMHO.

[aarongable]

@jvanasco

I would like to clarify the discussion in that thread was not about Chain Selection, but instead about a Server communicating to Clients the Available Chains / Roots before making any expensive or metered requests in the ACME Order process -- instead of in the last step of the ACME protocol.

Yes, apologies, I didn't mean to suggest that your thread was about anything else, just that -- thanks largely to my misunderstanding of what you were aiming for! -- it ended up talking extensively about profiles.

@orangepizza

with profiles will they include must-staple-or not version?

They certainly could! And they almost certainly would... if it weren't for the fact that OCSP is in the process of being replaced by browser-preprocessed-CRLs, and so "ocspMustStaple" will likely become irrelevant in the near future.

@Nummer378

Whether you're getting the RX or EX chain depends on the key type you submit. The profile doesn't affect this. Remember that the allowlist for ECDSA will eventually be removed. Profiles don't sound like a drop-in replacement for it.

A CA definitely could offer a "rsa" profile and an "ecdsa" profile, allowing clients to use the profile selection mechanism to determine whether their cert gets issued from an RSA intermediate or an ECDSA intermediate. Let's Encrypt could do this, but I think it is unlikely that we will -- we already have an RSA vs ECDSA selection mechanism (based on your public key type) and we have more important things to focus our profiles around.

[jvanasco]

@Nummer378

@orangepizza

with profiles will they include must-staple-or not version?

I don't see why they should. ACME has previously handled this via CSR so its easiest to leave it this way.

Yes. @aarongable has mentioned in several places they want to move this - and other attributes - onto profiles and away from CSRs.

In the above notice:

@aarongable

• 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.

And in the other thread this example:

@aarongable

       "profiles": {
         "default": "The profile that Let's Encrypt has been using for the last 6+ years.",
         "short": "The same as 'default', but with a validity period of 10 days.",
         "minimal": "A stripped-down profile with a short lifetime, no OCSP, no keyEncipherment KU, no clientAuth EKU, etc."
       }

I am +1 on removing everything from the CSR and shifting to profiles or other. While it had an important role in ACME v1 as the genesis of the ACME Order and could be generated by a Client or Subscriber, in ACME v2 it is expected to be carefully constructed by the Client – and CAs have been handling unsupported situations differently (mostly within RFCs). I don't think we're likely to see RFC updates to address this, as there are too many CAs at this point who are utilizing the "flexibility" of the RFC here - so adopting profiles would address these situations fairly decently by shifting a focus onto the alternate method.

[schoen]

@aarongable Do you think it would be helpful to have some machine-readable information in addition to the human-readable description?

The two examples that come to mind are "sampleChain" (PEM string?) and "minValidity"/"maxValidity" (in hours?). More controversially, maybe "subjectKeyTypes"?

Of course, it should be made clear in that case that (1) these properties are not guaranteed to be provided for any profile and there could always be profiles that aren't annotated with any machine-readable description, (2) these properties are not exhaustive and there may be others that will be defined in the future, and (3) these properties don't replace or restate the CA's actual policies, which may limit the availability of profiles to users in various ways.

An argument for this is that then a client could have a policy like "always prefer RSA", "always prefer PQ", "always request the shortest available certificate", or "always request the longest available certificate", and those policies could be relatively accurately implemented by the client.

[aarongable]

@schoen

Do you think it would be helpful to have some machine-readable information in addition to the human-readable description?

On the one hand, I'm not wholly opposed. I recognize the utility that could come from having some machine-readable descriptions that clients could use to differentiate between profiles and make selections automatically.

However, one of my primary design constraints here is client adoption. Adding a few properties like this is trivial on the server side -- it's just a few extra hand-crafted fields in the largely static directory object. But handling these fields is a huge amount of client implementation effort:

• Additional parsing, of data structures with potentially unknown keys and non-standardized values
• Custom configuration, to allow a client operator to express preferences
• Matching that configuration to the advertised parameters, perhaps using messy heuristics
• And finally a full-on optimization problem to compare the parameters advertised by multiple profiles (or even multiple CAs) and decide which one "best" matches the preferences expressed by the operator

I don't think I'm interested in standardizing something that I believe few if any clients will fully implement. So right now my approach is to keep this very simple: the smallest possible change that gives CAs and clients some additional flexibility, without requiring a huge change on any party's behalf.

[jesperkristensen]

This is a very interesting proposal. Weather the profiles should have machine readable metadata is an important aspect. If there is no machine readable metadata, the URL query parameters solution mentioned as reference in the OP seems better than the proposed solution. It would not require any client changes, which could ease adoption. Even if clients do adopt the proposal, configuration for a client who wants to use multiple CAs as backups, might still be easier using URL query parameters. The configuration would still be a list of URL strings, instead of a list of more complex configuration objects for CAs that don't need EAB. Let's Encrypt could even offer a configuration tool on its website where you could select your use cases and it could spit out a recommended directory URL with the right query parameters. And the decision of using one enumration or multiple flags could be changed later by each CA if needs change, without requiring client changes.

[orangepizza]

when we don't have machine-readable info, I have to ask what's that really different between list of directory URIs from profile URI? LE already did pseudo-profile with directory URI, for example acme-v02.api.letsencrypt.org vs acme-v01.api:

[aarongable]

@orangepizza

LE already did pseudo-profile with directory URI

Unfortunately I don't think this is really accurate. The difference between the acme-v01 and acme-v02 directory URLs was not in the content of the resulting certificates, but in the sequence (and content of) request messages a client would have to make to get issuance. They were different APIs/protocols, with different software running behind them. Different URLs was basically a necessity.

@jesperkristensen

If there is no machine readable metadata, the URL query parameters solution mentioned as reference in the OP seems better than the proposed solution

It sounds like you argument is that query parameters provide just as much, if not more, flexibility as in-message profile selectors, at a lower client implementation cost. This is a good point! Despite that, I'd still like to move towards something in-protocol specifically so that it can be standardized. But maybe this informs the expressivity of that in-protocol selector.