dwmw2 at infradead.org
Fri Jul 27 06:47:52 PDT 2012
On Fri, 2012-07-27 at 09:14 -0400, Dan Winship wrote:
> On 07/27/2012 04:30 AM, David Woodhouse wrote:
> > What we *haven't* solved yet is the configuration GUI, which is why you
> > have to edit the config manually. I've been pointed at
> > http://developer.gnome.org/gcr/stable/GcrComboSelector.html but AFAICT
> > there's no existing simple way to make a GcrCollection from all the
> > available certs in all the tokens known to p11-kit.
> Yeah, we're probably going to need some new widgets and stuff.
> > (Note that "all the certs which have corresponding private keys" is not
> > what we need, because sometimes the private keys aren't *visible* until
> > you log in to the token.
> Hm... it's not even possible to see that the key exists?
Right. On the Feitian PKI eToken that's sold at gooze.eu for use with
Linux, 'p11tool --list-all' will show the *cert* but not the
corresponding private key unless you 'p11tool --list-all --login'.
There are apparently some even more pathological cases where the *cert*
doesn't show up either; you have to log in to the token before it'll
even show *that*. So our cert-selection GUI will probably have to give
us a way to log in to certain tokens, to browse their contents.
> > And then there's the fact that we
> > *also* want to be able to choose a file from the local file system.
> Right, although do we want "choose a file and then import it into
> gnome-keyring and use PKCS#11" or "choose a file and then pass it to
> openconnect as a filename" ?
We had this conversation. We *have* to support the latter. You MUST NOT
silently copy my private key from the location I placed it, and store a
copy of it somewhere else.
For example... our company security policy is that certificates are
stored in ~/.cert and the passphrase on them is the UUID of the file
system on which they're stored ('stat --file-system --printf=%i\\n
~/.cert'). It's crazy, but it's what the IT folks have approved. It was
actually my suggestion, because it approximates the security of the
'non-exportable' flag in the Windows certificate store — it prevents the
naïve user from copying certs from one machine to another, and will stop
a determined user/attacker for about 30 seconds. It's what they
understand, so it's what they approve of.
There are slightly saner cases where a 'file' is used too — it might
just be stored on a USB stick, and the user expects that it *doesn't*
get copied onto the system from which it's used.
Using the file in-place also means that when the 6-month lifetime of the
cert is expiring, we can easily issue a new one and don't have to
reconfigure the VPN. We just overwrite the file. That would break too,
if you were to silently import the file to some other storage.
> > So yes, Dan's suggestion that we make pkcs11-helper use PKCS#11 URLs
> > seems sane. Note that we'll *also* want to make it load the tokens
> > specified in /etc/pkcs11/modules/, or it still won't work because it
> > won't *load* the right tokens and won't be able to resolve URLs.
> Not a problem:
> openvpn --pkcs11-providers /usr/lib64/p11-kit-proxy.so --pkcs-id ...
Hm, ok. So perhaps the openvpn in Fedora (and every other sane distro)
should be made to use p11-kit-proxy.so automatically if a pkcs-id is
given (perhaps only if it starts 'pkcs11:'), and no other provider is
> > Perhaps we want to make pkcs11-helper *use* p11-kit internally?
> The pkcs11-helper author didn't seem to like the idea of having the
> modules configured globally:
OK, it sounds like pkcs11-helper should be deprecated (in the distros)
and we should convert every existing user to something like p11-kit. Can
we add a p11-kit-openssl which would fill in the gaps and allow openvpn
to use p11-kit?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6171 bytes
Desc: not available
More information about the p11-glue