On Fri, Feb 04, 2022 at 04:06:10PM +0100, Tobias Meyer wrote:
> > Sorry, only PEM files are supported (for SNI the base64 encoded content
> > the file may need to be copied into a database table via "postmap -F").
> >
> > Support for PKCS#11 is not presently available.
>
> Since OpenSSL already supports PKCS#11 and Postfix uses OpenSSL, do
> you think adding support might be a task someone with a little C/C++
> background and a solid, but not expert, understanding of PKI could
> tackle, or would you recommend against that?
There are some non-obvious interface design obstacles. How does PKCS#11
work in chroot jails? In processes that drop privileges? What is the
interface to SNI? How does PKCS#11 play with the new "chain_files"
interface to specifying key+certs?
Loading a PKCS#11 provider is different in OpenSSL 3.0 vs 1.1.1, and
would probably require implementing a Postfix interface to loading
custom "openssl.cnf" files, and perhaps delegating some additional
configuration settings to OpenSSL that are presently managed explicitly
in Postfix.
So I don't think this is a straightforward project.
> Alternatively, would this be the place to ask for a feature request? :)
Sure, but this is unlikely to get immediate attention. For now just
plan to rotate keys often enough for absence of an HSM to not matter.
That is, avoid the traditional one year or longer certificates, and roll
certificates every 90 days or less. A PEM key file is good enough in
practice for all but the most valuable keys.
Unless you're running a public CA, or a corporate CA issuing credentials
with "keys to the kingdom", or must use the same key for years, an HSM
is generally overkill.
--
Viktor.
