What does support mean for x/crypto/acme?
Do you have a proposed set of api changes?

What does support mean for x/crypto/acme?

I believe it means a few small non-intrusive and backwards compatible changes.

Do you have a proposed set of api changes?

I could do these in increments too to make it smaller/easier to review but the following is likely necessary:

1. Update Directory to include a Profiles attribute with type map[string]string. Given this is not yet an RFC, it may be more forward-compatible with any potential alterations to the RFC to make this a distinct type like net/http.Header. That way there's more control over the API and how one might keep backwards compatibility with any post RFC-acceptance changes.
2. Add a new OrderOption, e.g., WithProfileName(s string) OrderOption WithOrderProfile(name string) OrderOption to be used with AuthorizeOrder which implies updating the anonymous struct definition to include the profile attribute as something that's omitted if empty.

I'd want to add plenty of test coverage here as well just to make sure this doesn't interfere with existing behaviour.

I do believe this will be minimally invasive. This could also be "smarter" in that if someone provides WithProfileName WithOrderProfile but no Profiles exist from the directory endpoint or the profile name itself isn't in the map, then it returns an error without making a request to the server.

It wasn't much work to stub out what I was thinking of above, so I pushed it to a fork before submitting via Gerrit in case that helps https://github.com/sigmavirus24/golang-x-crypto/tree/proposal/73101

@seankhliao how can I help drive this discussion further?

Given it's still a draft, I don't really see it being added anytime soon.

cc @rolandshoemaker @golang/security