For ease of discussion, I have proposed this edit in a PR here: https://github.com/aarongable/draft-acme-profiles/pull/16
Thanks, Aaron On Thu, Sep 11, 2025 at 3:19 PM Aaron Gable <aa...@letsencrypt.org> wrote: > Yeah, I think I'm generally fine with making that change. The only reason > I made the client-side change in the new -00 draft, but not this > corresponding server-side change, is that I was hoping this exact > conversation would continue. > > I think I might prefer something *slightly* stronger, though. In > particular, I don't think it's a good idea for servers to accept requests > for a specific profile, but silently remap them to a different profile. I > think the plain "it SHOULD reject" language can easily lead to an > interpretation that the server can accept-but-modify requests for profiles > it doesn't advertise. > > So maybe something like this: > > The server SHOULD reject all newOrder requests which specify a profile > that the server is not advertising, and MUST reject all newOrder requests > which are incompatible with the rest of the contents of the request (e.g. a > "tls-server-auth" profile alongside an identifier of type "email", or a > "super-special" profile requested by an account which is not on the > appropriate allowlist). In such cases, it MUST respond with a problem > document of type "invalidProfile" (see Section 6.3). > > WDYT? > > On Thu, Sep 11, 2025 at 1:32 PM Mike Ounsworth <ounsworth+i...@gmail.com> > wrote: > >> > 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 <benburk...@anchor.dev> 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 <aa...@letsencrypt.org> >>> 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 < >>>> ounsworth+i...@gmail.com> 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 <benburk...@anchor.dev> >>>>> 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 <aa...@letsencrypt.org> >>>>>> wrote: >>>>>> >>>>>>> Hi Ben, >>>>>>> >>>>>>> On Thu, Aug 7, 2025 at 6:32 PM Ben Burkert <benburk...@anchor.dev> >>>>>>> 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 >>>>>>>> <ietf-secretariat-re...@ietf.org> 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 -- acme@ietf.org >>>>>>>> > To unsubscribe send an email to acme-le...@ietf.org >>>>>>>> >>>>>>> _______________________________________________ >>>>>> Acme mailing list -- acme@ietf.org >>>>>> To unsubscribe send an email to acme-le...@ietf.org >>>>>> >>>>>
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
