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]
