[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 <[email protected]> wrote: > > Aaron Gable <[email protected]> wrote: > > On Fri, Jan 9, 2026 at 10:33 AM Michael Richardson < > [email protected]> > > 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 [ > ] [email protected] http://www.sandelman.ca/ | ruby on > rails [ > > > > > > > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > _______________________________________________ > Acme mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
