On Tue, May 05, 2026 at 09:48:34PM +0300, Mia Kanashi wrote: > Subject: Re: [PATCH 3/4] MINOR: acme: implement EAB - external account binding > > You should probably split this commit in two, introduce the HMAC in the > jws > > first, then use it in the ACME code. > > Sure. Also makes sense to jws_b64_protected() into a separate commit > from jws_b64_hmac_signature() maybe, as they are unrelated. > > > I don't know if that's a good idea to use crt-base here, if it's not a PEM > > certificate we will probably need something else to configure the path. > Like an > > acme-account-path or something like that. > > Yeah, it is not PEM, also, because it isn't PEM .key extension may be > confusing, > I should probably change the preferred extension. > And by that logic it shouldn't be related to the crt-store. I'm not sure. > At the same time I think it makes some sense for them to be in the same > location > as the account-key, they are the account credentials. > > Now that I think about it, current behavior seems strange, what if I refer > to > the same acme section within multiple crt-store sections? Will that make > multiple accounts currently?
Only 1 private key account is created by section, so the ACME server will find the account related to this key and reuse it for every certificates. > For a name "acme-base" would make the most sense in my opinion, > similar to ca-base, key-base, crt-base. > > acme-base or acme-account-base can be an option on the acme section, > or maybe global section, and it will specify acme account related paths for > it. > So example.com.pem will be relative to crt-store, but pebble.account.key and > eab credentials will be relative to the acme-base. > What do you think? That is a breaking change. > > Do you have any thoughts with regards to EAB creds implicit file loading > behavior? > I think I will remove it, it makes thinks more confusing, and probably > add a warning when file isn't found or empty. > I want to have some option to remove credential without changing haproxy > config. > Maybe also what would make sense is to allow only empty files, but they > should > still exist, so that use case will be covered, > or can make the parsing being just in time, though I don't like it that > much. > I'm wondering if this is a good idea to rely on a file for this. It's only 2 shorts strings, doesn't it make sense to put that directly in the configuration? I fear it complexifies the file handling without much benefits. > Do you prefer if I submit next patch as a reply to this thread or as a > completely new mail, or don't care? You can rebase directly from master, then send your series again with a git-send-email -v2 --in-reply-to=... with the latest email ID of the current thread. -- William Lallemand
