Re: [Acme] Proposal: ACME Profiles

[Deb Cooley <[e-mail]>]

Aaron,

Also (very) late to the game, and my experience is mostly with private CAs:

We have used certificate profiles for decades, but not with ACME.  These
profiles are currently specified in a document called 'certificate
profiles'.  Even in our most widely used systems (that issue to more than
TLS), there aren't more than 20-30 profiles.  Generally, we specify the
algorithm/key size choices w/in a single profile (currently one can choose
RSA 2K or above and ECDSA w/ P384, for example).  Certificate validity is
done the same way (less than x time).  What does vary are the KU and EKU
fields for each profile, where some EKUs are mandatory and some are
optional.  These profiles have very simple names.  When a request is made,
as long as the CSR matches the options we have given them in the profile,
the cert is issued.

I think this old school method should scale to ACME without too much
trouble.  There would need to be a default profile for your old
clients/accounts.
And the profile offerings can be set by what EKUs are chosen (where there
are both mandatory EKUs and optional EKUs).  Having this profile ability
will allow the use of ACME CAs in more areas than just TLS.

My last comment is that this should be kept simple.  Most server operators
struggle today, and get it wrong.  The simpler we can keep it, the more
likely they will be to configure it correctly - enabling secure
communications.

Deb




On Tue, Sep 19, 2023 at 8:33 PM Matthew McPherrin <mattm=
[e-mail]> wrote:

> My personal opinion here is that adding a profile field to the Order
> object is likely to hamper client adoption, and as Ben just said, makes
> configuration more difficult if CAs don't have matching profiles.
>
> An alternative approach that I believe has been used is adding URL
> parameters to the directory URL, as Aaron mentioned in his initial email.
>
> The returned URLs in the directory can reflect those parameters, eg, on
> the newOrder endpoint, as required.
>
> The directory endpoint should only do so if the parameters are known.
>
> The directory url can contain metadata to advertise what parameters are
> available.
>
> So potentially an interactive client can display a UI of options to a user.
>
> Automated use-cases or older ACME clients would simply configure the
> directory URL as desired, with the query parameters included.
>
> I believe that adding parameters to directory URLs requires no additional
> standardization work, and Let's Encrypt can add a profile parameter
> immediately.
>
> What we may want to standardize is a method for advertising what query
> parameters are available, as well as a mechanism for returning warnings or
> errors about invalid or deprecated flags in the directory.
>
> Thanks, Matthew
>
> On Tue, Sep 19, 2023 at 7:17 PM Ben Burkert <[e-mail]> wrote:
>
>> Hello,
>>
>> Apologies for chiming in late here; I'm with a startup that is just
>> coming out of stealth mode so I have been quietly following these
>> discussions. I bring this up because we build & operate ACME powered CAs
>> on behalf of users, and we've already introduced our own concept similar
>> to profiles. We focus entirely on the private CA market, but we have an
>> interest in seeing this concept standardized in a way that works well
>> for both the public & private ACME CAs.
>>
>> The way we solve this is at the intermediate CA level, which we refer to
>> as a SubCA. Each SubCA is an intermediate CA that issues end entity
>> certs, and a template that sets a common set of properties of the end
>> entity certs that it issues. For example, when creating a SubCA you can
>> specify the expiry time (as a duration), key usage and other extensions,
>> and allowed DNS/IP naming rules (which can turn into name constraints on
>> the intermediate).
>>
>> This works for us because creating new intermediate CA is easy to do in
>> our model. Also, we require EAB tokens on all ACME requests, and we
>> scope those tokens to specific SubCAs. This means clients effectively
>> pick a profile by picking a SubCA when creating EAB tokens.
>>
>> So we have something similar that works well for us today. But even so,
>> there are a whole bunch of business reasons I could go into about why we
>> would like to see a standardized profile concept. A lot of the reasons
>> probably aren't relevant to public CAs though, so I'll stick with my
>> thoughts related to public CAs.
>>
>> The "combinatorial explosion" of profiles seems like a bigger issue for
>> client authors and end users than for the CAs. If i'm trying to setup
>> multi-CA resiliency, today I only have to add some fallback directory
>> URLs and duplicate the manual or automated work to fulfill challenges.
>> But with profiles, does that mean I have to go to each CA and figure out
>> the right set of profiles? I don't like the added friction of having to
>> manually perform this intersection of policies.
>>
>> I think Rufus' idea about allowing profiles to point to other CAs could
>> address some of the "combinatorial explosion", but it could also
>> introduce centralization.  What happens when a CA hosting a popular
>> profile disappears? Or makes changes to the profile?
>>
>> >From an end user's perspective, picking a profile is a lot like
>> requesting a set of capabilities. Maybe there is a way to encode these
>> capabilities in a logic programming language. Something along the lines
>> of Biscuits[1], which has the nice properties of immutability and
>> attenuation. Making the profile object both resource and content
>> addressable could avoid "combinatorial explosion" without
>> centralization. And using machine readable logic language programs as
>> the standard format for profile objects could allow for "flags" without
>> some of the drawbacks that Matt brought up.
>>
>> [1] https://www.biscuitsec.org/
>>
>> Cheers,
>> -Ben
>>
>> On Wed, Aug 30, 2023 at 6:21 PM Aaron Gable
>> <aaron=[e-mail]> wrote:
>> >
>> > 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 is largely an exercise
>> in profile selection. There’s also been significant discussion 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
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/acme
>>
>> _______________________________________________
>> Acme mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/acme
>>
> _______________________________________________
> Acme mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme
>