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]
