Aaron, 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. > > I think we're in agreement that it would be bad for clients to require an additional request to "check" the profile before every new order. And I think instructing users to pick a profile out-of-band of the ACME workflow makes sense, given that (as you said) the vast majority of ACME clients are statically configured. I brought up the idea of a new endpoint as a way of satisfying the requirement that the server MUST advertise the profiles that a new order uses.
Would you consider switching "it MUST reject" to "it SHOULD reject" in section 4? For my use case, I believe that would side-step any need for an additional way for the server to advertise profiles. On Thu, Sep 11, 2025 at 1:52 PM Aaron Gable <[email protected]> wrote: > 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]
