PKCS #11 support request

[vanrein]

Would you consider adding PKCS #11 support to acmetool? Though it would be possible to import the generated keys afterwards, it beats the purpose of using this private-key-protective API.

Apache supports use of PKCS #11 private keys and even certificates via PKCS #11, which generally is helpful to avoid that private keys are ever revealed. It remains an operational choice what implementation of the PKCS #11 API to use; it could be a software implementation, a simple USB token or a more advanced rack-mounted redundant key management solution for tens of thousands of dollars. With PKCS #11, key management quality is a choice.

This range of operational choices is why we use it in our TLS Pool project, which additionally separates TLS handling from the application process via file descriptor passing and reduces TLS implementation to one API call, fd = starttls_client (fd, ...). We intend to use that in security/privacy projects like Keyful Identity Protocol and Realm Crossover for Kerberos.

Just ask if you want to learn more about PKCS #11. These are a few speciication links that you might find interesting:

• PKCS #11 Base standard -- there are extensions such as for the set of security mechanisms.
• p11 URI standard and a commonly used implementation

[vanrein]

I can see two ways of adding PKCS #11 support that might work without building it into acmetool.

• You might allow want notation that installs a public key and (something that handles like) a private key. In case of PKCS #11, the latter could for example be a pkcs11: URI. I am assuming that the private key is not actually used by acmetool, but merely passed as a blob after it was generated.
• You might allow a hook for keypair generation, in which case rollovers of key pairs are possible even when PKCS #11 is used.

If my suspicion is correct, then PKCS #11 could be "hacked in" with the target file's request.key but it feels that would be blasphemic, and possibly unstable. Tool integration, even as lightweight as above, is preferred. Or is it merely a matter of documenting this use case? I am unsure.