pkcs#11 URIs

David Woodhouse dwmw2 at
Sat Jul 28 04:06:48 PDT 2012

On Sat, 2012-07-28 at 12:56 +0200, Stef Walter wrote:
> Think users moving, deleting the file, or unmounting, and all sorts of
> stuff.

I'm thinking of exactly that. If I delete the file or unmount the
removable or encrypted file system on which it resides, the system MUST
NOT be able to connect to the VPN any more. That's probably *why* I
deleted or unmounted it. If you tell the security folks "actually it's
OK, we squirrelled away a copy of the key so that we can connect
automatically in future and it's stored in some new storage that you
haven't vetted for security"... they're going to have a fit.

I'm also, as I said, thinking of the case where I *overwrite* the key
with a new one, because the old one is about to expire.

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

Yes, it already has to. The command line tool is never going to ditch
support for using keys from files, and go to *only* PKCS#11.

That's why I've just added support for interpreting the old horrid
OpenSSL encrypted PEM files, even when using GnuTLS. Etc.

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

In fact, when invoked through NetworkManager the authentication part
(which uses the cert) *is* running in the user's own session. We make
the *connection* as root, using a cookie which is obtained from a
successful authentication.

We have to support *both* modes of operation.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <>

More information about the p11-glue mailing list