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
