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 _______________________________________________ Gnutls-help mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-help
