Looks great to me, thanks! On Thu, Sep 11, 2025 at 6:23 PM Aaron Gable <[email protected]> wrote:
> 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 <[email protected]> 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 <[email protected]> >> 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 <[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]
