I'm sympathetic to the idea that a CA may want to change the set of available profiles based on which account is asking. After all, even Let's Encrypt is currently advertising a "shortlived" profile, but the vast majority of accounts would receive an error if they actually request that profile, because it is currently locked behind an allowlist. I can certainly see that it might be a better user- or client-experience for that profile to not be advertised at all unless you're on the allowlist.
That said, I'm not sure how to actually go about doing that. Yes, of course we could just add a "profiles" endpoint which is accessed via POST-as-GET and can therefore contain account-specific content. But suppose you're a human setting up an ACME client for the first time. You have three different ACME CAs you're choosing between. Do you really have to create an account -- and therefore manage a private key -- for all of them, just to see if one of them offers a profile that you want to use? That seems like a terrible user experience. Similarly, explicitly enshrining the distinction between "public" profiles (which appear in the directory) and "private" profiles (which appear only in the profiles endpoint) feels like one too many layers of complication. All ACME clients would end up having to query the private profiles endpoint at the beginning of every issuance cycle "just in case", at which point we're just wasting bandwidth and request cycles. Beyond all that, it sounds like some CAs have an answer for this problem already: handing out unique directory URLs to subscribers. I don't think it's the place of this protocol extension to solve directory ennumerability problems. Aaron On Thu, Sep 11, 2025 at 10:21 AM Mike Ounsworth <[email protected]> wrote: > Hi Aaron and Ben, > > [chair hat off] > > I think the interesting discussion here is whether a certificate profile > is a static and public thing, or whether a profile could be a dynamic or a > private thing. It's an interesting question. Certainly the majority > use-case (and probably the only one that Let's Encrypt cares about) is that > profiles are in lock-step with CA/B F BRs, which makes them static(ish) and > public. But I could imagine private CA / people CA things where: > > * Cert profiles are dynamic based on the user's properties; for example if > the user's Windows account is tagged with [vpn_client], [tls_client], > [wifi_client], then they will get a cert with all those extensions. In that > case, maybe it's not unreasonable to use the UserID as the ProfileID? (I > know that ACME doesn't really serve this use case today, but it's headed > that way with the acme-client draft.) > * The CA offers cert profiles that they don't really want to advertise > publicly, like some sort of super-admin, or military profile, or profiles > for backend components of the CA itself. > > I can also imagine that the CA is allowed to change its offered cert > profiles, so you pull the list of offered profiles from the ACME Directory > at time t, and by the time you submit your NewOrder at t+1, that cert > profile is no longer offered. > > I can see that this makes the MUST / MAY / SHOULD's a bit tricky here. > > On Thu, 11 Sept 2025 at 12:07, Ben Burkert <[email protected]> wrote: > >> Hi Aaron, >> >> I'm happy to update the client language to SHOULD NOT, as that's a more >>> reasonable standard for a client to adhere to (esp since there's an >>> inherent race between fetching the Directory and submitting a newOrder >>> request, during which time a profile could be removed by the server). >>> >> >> Great! >> >> There has not. I will admit I don't quite see the benefit. The vast, >>> vast majority of ACME clients are statically configured, not interactive. >>> On the assumption that a client has been configured to request the >>> "super-coolio" profile, why would it be beneficial for the client to >>> discover that that profile isn't offered by making a /acme/get-profiles >>> request, rather than to discover the exact same thing by making a >>> /acme/new-order request? The failure mode is the same: log an error, notify >>> the operator that the requested profile isn't available, and either abort >>> issuance or fall back to whatever the CA offers as the default profile for >>> your request. So why add an extra round-trip to the protocol that won't >>> ever provide meaningfully novel information? >> >> >> Thanks for the extra context. I don't have an opinion on the best way for >> the client to be informed that a profile is invalid, and your point makes >> sense here. I'm thinking about the requirement that a server must advertise >> the profile that can be used in a new order. I mangled this quote from >> Section 4 in my previous email: >> >> If the server receives a newOrder request specifying a profile that it is >>> not advertising, ... it MUST reject the request with a problem document of >>> type "invalidProfile" (see Section 6.3). >>> >> >> Changing this MUST to a SHOULD would help my use case remain compliant >> with the spec. Otherwise, I'd need an additional way for the server to >> advertise profiles. >> >> Thanks, >> -Ben >> >> >> On Fri, Sep 5, 2025 at 6:52 PM Aaron Gable <[email protected]> wrote: >> >>> Hi Ben, >>> >>> On Thu, Aug 7, 2025 at 6:32 PM Ben Burkert <[email protected]> >>> wrote: >>> >>>> > Section 4: >>>> > The client MUST NOT request a profile name that is not >>>> > advertised in the server's Directory metadata object. >>>> > ... >>>> > If the server receives a newOrder request specifying a profile that >>>> > it is not advertising >>>> >>>> I would like to see these sentences removed or altered from MUST NOT to >>>> SHOULD >>>> NOT. My concern is that it makes CAs that provide profiles based on an >>>> account >>>> (be it an ACME account or external CA account) non-compliant with this >>>> specification. >>>> >>> >>> I'm happy to update the client language to SHOULD NOT, as that's a more >>> reasonable standard for a client to adhere to (esp since there's an >>> inherent race between fetching the Directory and submitting a newOrder >>> request, during which time a profile could be removed by the server). >>> >>> >>>> >>>> Without this language, an ACME server could accept personalized >>>> profiles in an >>>> order that was not present in the directory profiles. It is not >>>> practical for >>>> the ACME service I work on to publish all profiles in the directory, >>>> and even >>>> if it was not all profiles would be available to all accounts. >>> >>> >>>> It also introduces a security issue because directory requests are not >>>> authenticated. For services like ours that provide per-account ACME >>>> endpoints, >>>> we serve a directory response for any request that could be a valid >>>> directory >>>> URL. This is to prevent enumeration attacks, so if we were to include >>>> per-account profile information in the directory we would be adding a >>>> vector >>>> for enumeration. >>>> >>>> Has there been any discussion about adding a POST-as-GET style >>>> "profiles" >>>> endpoint? >>>> >>> >>> There has not. I will admit I don't quite see the benefit. The vast, >>> vast majority of ACME clients are statically configured, not interactive. >>> On the assumption that a client has been configured to request the >>> "super-coolio" profile, why would it be beneficial for the client to >>> discover that that profile isn't offered by making a /acme/get-profiles >>> request, rather than to discover the exact same thing by making a >>> /acme/new-order request? The failure mode is the same: log an error, notify >>> the operator that the requested profile isn't available, and either abort >>> issuance or fall back to whatever the CA offers as the default profile for >>> your request. So why add an extra round-trip to the protocol that won't >>> ever provide meaningfully novel information? >>> >>> Thanks, >>> Aaron >>> >>> >>>> >>>> Cheers, >>>> -Ben >>>> >>>> On Wed, Aug 6, 2025 at 4:00 PM IETF Secretariat >>>> <[email protected]> wrote: >>>> > >>>> > >>>> > The ACME WG has placed draft-aaron-acme-profiles in state >>>> > Call For Adoption By WG Issued (entered by Mike Ounsworth) >>>> > >>>> > The document is available at >>>> > https://datatracker.ietf.org/doc/draft-aaron-acme-profiles/ >>>> > >>>> > Comment: >>>> > CfA started 2025-08-06, runs until 2025-08-20. >>>> > >>>> > _______________________________________________ >>>> > 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] >> >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
