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
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
