[Acme] Re: Call for adoption: draft-davidben-acme-profile-sets-00 (Ends 2026-01-21)

[Mike Ounsworth <[e-mail]>]

[still chair-hat off]

Aaron said:

> This is exactly what happens today. If a client submits a CSR containing
an unacceptable key algorithm, the CA rejects it with
urn:ietf:params:acme:error:badCSR and a descriptive message stating what
was wrong. ACME doesn't help clients automatically figure out what key to
use. ACME Profiles doesn't help clients automatically figure out what key
to use. Why would ACME Profile Sets be expected to do so?

I think think this discussion has finally gotten to the core of the issue,
and this comment from Aaron is it.


Facts:

* The "A" in "ACME" stands for "Automated". In its design, we should be
aiming to increase automation and reduce error conditions that need human
intervention.
* There are CSRs that a CA will reject because the client key algorithm is
bad or unrecognized, such as RSA-512, or ECDSA with some custom curve, or
some wild experimental PQ algorithm.
* We can speculate about how CA/B F will handle this in the future, for
example will an RSA CA be allowed to issue certs for ML-DSA EEs? But in my
opinion we don't have enough clarity to bake these into underlying
assumptions of standards documents.
* ACME as it exists today does not allow for automation of the choice of
client algorithm -- the ACME order will fail with an error requiring human
intervention (ie you configured it wrong).
* draft-ietf-acme-profiles helps this problem because it's still static
config: if your first request against a given profile succeeded, then every
subsequent request should also succeed. IE it still fits the
"set-and-forget" paradigm. And profiles gives CAs a way to make big
breaking changes (like a new root that may not have full adoption) and put
that under a new profile, and then do the normal adoption-deprecation thing.
* draft-davidben-acme-profile-sets-00 undoes this by introducing a layer of
non-static config that the CA is free to change at any time, which I'm
afraid makes ACME no longer "set-and-forget" because the CA could, for
example, add a new profile to the profile-set, and that could cause an ACME
Client to blow up, requiring manual intervention and leaving your TLS
servers without certs.

So my personal opinion is that DavidBen has presented an interesting
problem -- if we imagine that in the future, TLS servers will get maximum
interop by being provisioned with multiple certs, then does it help for the
CA to advertize bundles of recommended cert profiles? But it's not clear to
me that this is a problem that needs to be solved. And even if the problem
statement is sound, I fear that the proposed solution introduces harmful
error cases to ACME that could cause a working ACME client config to
suddenly start throwing errors and grind your prod env to a halt if the CA
changes the profile-set in a way that the ACME Client can't handle -- IE
this draft breaks the "set-and-forget" nature of ACME. So, unfortunately, I
feel that this document is not ready for adoption.


[chair hat back on]
I will circle up with my co-chair to objectively review this thread and
make an official consensus call.

On Sat, 10 Jan 2026 at 11:19, Michael Richardson <[e-mail]>
wrote:

>
> Aaron Gable <[e-mail]> wrote:
>     > On Fri, Jan 9, 2026 at 10:33 AM Michael Richardson <
> [e-mail]>
>     > wrote:
>
>     >> Why not?  Will an ACME CA sign certificates with arbitrary
> algorithms
>
>     > present?   Can I have DSA-768?  Or RSA-8192 keys?  Or DAGS (one of
> the
>     >> defeated algorithms from PQ-round 1)?  Can I use MD5 as the hash?
>     >> The answer I hope, is no.  So, CAs *DO* determine what keys are
> used.
>     >> But, this profile system doesn't actually help end users know what
> to do.
>     >>
>
>     > This is exactly what happens today. If a client submits a CSR
> containing an
>     > unacceptable key algorithm, the CA rejects it with
>     > urn:ietf:params:acme:error:badCSR and a descriptive message stating
> what
>     > was wrong. ACME doesn't help clients automatically figure out what
> key to
>     > use. ACME Profiles doesn't help clients automatically figure out
> what key
>     > to use. Why would ACME Profile Sets be expected to do so?
>
> The document says:
>
>    [I-D.ietf-acme-profiles] defines ACME profiles, a mechanism for ACME
>    Clients to choose between different certificate profiles from a
>    single ACME Server.  However, in applications that require
>    certificates from multiple profiles, an ACME Client must know WHICH
>    PROFILES ARE NEEDED, and be updated over time.
>
>    This document extends ACME profiles with _profile sets_. A profile
>    set is a set of related profiles, defined by the ACME Server.  As
>    PKIs evolve, the ACME Server CAN UPDATE ITS PROFILE SETS TO REFLECT
>    RELYING PARTY NEEDS.  In particular, if satisfying all relying
>    parties with a single profile would be infeasible or inefficient, the
>    ACME Server can add a profile to the profile set.
>
> So, the purpose of this document is allow an ACME Server to indicate some
> interesting properties about it's profile(sets).    If an ACME client knows
> (as you say it must) that it needs key-type-A (with trust anchor from
> type-A)
> and key-type-B, then it ought to be able to find a profile that satisfies
> it.
> To do that, the profile(sets) need to machine readable.
>
>     >> I strongly disagree.
>     >> Of course, you can't use an algorithm that you have no operational
> code
>     >> for.
>     >> You also can't get a certificate signed for an algorithm the CA
> doesn't
>     >> understand.
>     >> The working thing is the common subset of the two.
>     >> If profiles or profile-sets can not tell the client what the CA
> would
>     >> accept,
>     >> then they are useless to me.
>     >>
>
>     > Repeating myself, why? An ACME directory URL can't tell you what the
> CA
>     > would accept, either.
>
> Who said these are directory URLs? I didn't.
>
>     > Now, I do think there is some nuance here. If, for example, a CA
> said that
>     > they were only going to use their classical hierarchy to issue certs
> over
>     > classical keys, and only use their PQ hierarchy to issue certs over
> PQ
>     > keys, then a profile set of {"defaultProfileSet":
> {"classicalProfile",
>     > "pqProfile"}} would likely be unworkable -- there's no way to tell
> the
>
> Unworkable because nothing here says anything about that policy.
> Only a human could guess that.
>
> (The names, I think we agree, are just sequences of letters, and have no
> meaning)
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT
> architect   [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on
> rails    [
>
>
>
>
>
>
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> _______________________________________________
> Acme mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>