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]
