pkcs#11 URIs

[Stef Walter]

On 07/27/2012 03:47 PM, David Woodhouse wrote:
> 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'.

Yeah, this is very common and is really a effect of the PKCS#11 API.
Anything with CKA_PRIVATE == CK_TRUE does not show up until you log into
the token. Sure there are module specific ways to work around this (like
some modules have a non-private CKO_PUBLIC_KEY for every private
CKO_PRIVATE_KEY), but it's not really something you can rely on.

Usually you use the certificate to locate an appropriate/configured
client side certificate, and if you find something, then you log into
the token and look for the corresponding private key there.

There are cases where a certificate and key are stored in different
slots/tokens. But I don't think we can support every strange PKCS#11
practice (and there are lots of them) from the get go. We need to make
this work with our initial tokens and then define/discover any other
common best practices.

>> 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" ?

In general we should have a selector for certificates that are already
in the user's stores (configured PKCS#11 tokens) and allow them to
import additional certificates from that same selector.

> 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.

Yes, we did have this conversation on IRC. I'm not against supporting
certificates in file locations as a *secondary* config option if necessary.

But I think that in general it's not something we want to support and
encourage in the user interface. If the user selects a certificate in a
certain location, and we don't import it, then there's a hundred ways it
can fail for all sorts of use cases.

Think users moving, deleting the file, or unmounting, and all sorts of
stuff. Then start thinking about all the various formats that
certificates can be in. We support tons of import certificate formats in
Gcr. That makes sense for an importer. Should openconnect support all
those formats? Nope.

In addition openconnect will be often running in a different security
context. Due to SELinux, NFS homedirs, and all sorts of other things it
can't reliably read locations like the home directory where the user has
write access.

The list of issues goes on and on.

So all in all openconnect should use stuff in PKCS#11 and not in
filenames. Dan Williams also brought this up strongly for the way he
thinks he wants this to work in network manager [1].

FWIW, I outlined the solution I'm working on for the SELinux and
permission problems [2].

> 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.

That's fine but not something that we should put into the user
interface. I mean look at your requirements, they're not UI friendly at
all. They include things like selecting/writing files to directories not
visible in the file chooser. console commands and so on.

For your use case I think you should either:

 * Deploy stuff automatically using scripts or a custom tool.

 * Use a (ficticious) PKCS#11 module which exposes these security
   requirements (expose stuff in ~/.cert, PIN set from filesystem).

In the latter case is of course hard to implement, so would only make
sense if lots of people have this security policy.

> There are slightly saner cases where a 'file' is used too — it migh
> 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.

Again, this will break with SELinux and other permissions and mounts
that don't allow root access. If we want to design for this use case we
should do it explicitly (eg: a separate PKCS#11 module, for making
'pretend' smart cards out of USB sticks) and not accidentally.

> 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.

This already doesn't work with libraries like NSS which don't support
files. We want to have this be a general solution.

So all that to say my opinion is that we should default to 'import'
style behavior in the user interface. I would strongly suggest that the
Network Manager selector for certificates to use with openconnect also
behave this way in the UI.

In general we should also be thinking of admin deployment use cases and
tools, and in my opinion that's the appropriate place for options and
security policy like the one you're describing.

> 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
> specifed?

I like :)

> 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?

That's a good idea if pkcs11-helper doesn't want to use p11-kit. Nikos
has also been requesting that we add some thin wrappers for easing the
use of the (nasty in parts) PKCS#11 API. There was talk of merging
pakchois, but we could also bring in some API in the style of
pkcs11-helper if it makes sense.

Cheers,

Stef

[1] https://bugzilla.gnome.org/show_bug.cgi?id=670198#c3

[2] https://bugzilla.gnome.org/show_bug.cgi?id=670198#c4