> Would you consider switching "it MUST reject" to "it SHOULD reject" in section 4?
Yeah, I think that's where I'm at too; I can imagine good reasons for a CA to have "hidden profiles", therefore I think SHOULD is better than MUST. On Thu, 11 Sept 2025 at 14:35, Ben Burkert <[email protected]> wrote: > 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]
