On Mon, Aug 18, 2025 at 03:46:58PM +0100, Christopher Staite wrote: > Hi William, >
Hi Christopher, > That’s exactly the kind of feedback I was after, thanks. Creating the > ability to load a PKCS#11 URI from the PEM and > then providing that information over some socket to a separate service to > handle it should work well and avoid the > complexity of implementing the threading model within HAProxy as I have done > in this patch. As I did it I really > disliked it, which is why I was after feedback in the first place. I think so as well, that might be the simplest implementation we can have. > Originally I hoped to make use of p11-kit to do exactly this: > https://github.com/p11-glue/p11-kit. However, the > external interface for it is itself a PKCS#11 module (p11-kit-client.so > <http://p11-kit-client.so/> which is > blocking). However, this interfaces with the p11-kit server over a UNIX > socket and I believe I can simply take the > synchronous code from the client and make it asynchronous within HAProxy. > The entry point for their client is here: > https://github.com/p11-glue/p11-kit/blob/master/p11-kit/client.c. > I don’t suppose it’s all that complex to provide support for the few > functions required to do signing. There’s a lot > of PKCS#11 functionality that I don’t think we care about at all. > What do you think about that for a solution before I take a crack at it? I didn't check everything which is provided by the PKCS#11 spec but indeed that could be enough to do only the signing. What's important is that we don't depend on external code on haproxy side. Having the p11-kit server loading the .so driver for the HSM, and exposes a UNIX socket seems perfect. So HAProxy just have to implement the client side of it. I just hope that we don't need to define specifics things for each drivers on the client side. But yes, if an equivalent of p11-kit-client.so in non-blocking mode within haproxy is implemented, that would be an elegant way of achieving the feature and it could work with multiple implementations of the protocol! Regards, -- William Lallemand
