[gnutls-help] Multi-tenancy and PKCS #11

[Rick van Rein]

Hi,

>> One thing that may be blocking it, is the fact that GnuTLS has a global
>> setup for PKCS #11, including the available tokens and their PINs.  Is
>> that correct, or is there a way to get around this?
>
> Could you describe the ideal situation of handling smart cards for the
> use case above?

The design alternative that I'm exploring is one in which the TLS Pool is
a networked component, serving to multiple daemons, and/or where each
daemon can run on behalf of various domain names.  Ideally, the credentials
of each domain name would be kept separate in the TLS Pool, rather than
trusting the daemon to do the right thing.  The daemon is closer to the
protocols and parsers of the application, after all, and the whole idea of
the TLS Pool is keeping application logic and security logic separated.

> The situation in gnutls is that pkcs11 shared modules
> are loaded globally, pins etc are cached/used per private key,
> operation.

The PINs may be the solution then.  You didn't write down the precise
logic, right?  Well you did, of course, in the code :) so maybe I should
take a look there.  I had assumed PINs were strictly delegated to p11-kit.

> Note that PKCS#11 utilizes global state per process

Yes, I've been thinking along the lines of separating the various
users (daemons/domains) of a networked TLS Pool into processes.  This
is not how we design all our systems these days, but it makes sense
from a security perspective to split PKCS #11 access into processes.
I'd have to see what that means to BerkeleyDB access too.

> and it may not be
> possible to have various modules loaded by different parts of the
> process without co-ordination.

That's what I was afraid of.  It's probably the way p11-kit works,
anyway, since PKCS #11 is considered a loaded library to a process.
I suppose separating processes is the best way forward then.

As you can tell, I'm in a sort of dynamic state on this, thanks for
helping me fence off the search space.


Cheers,
 -Rick