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?
> 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.
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
client that it should be generating different keys and submitting different
CSRs for the different profiles. Maybe there should be a requirement placed
upon the CA that any profiles which it groups into a profileSet MUST accept
the exact same classes of newOrder requests and finalize CSRs.
Aaron
_______________________________________________
Acme mailing list -- [email protected]
To unsubscribe send an email to [email protected]