pkcs#11 URIs

[Stef Walter]

On 07/28/2012 01:06 PM, David Woodhouse wrote:
> 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.

Windows, Mac OS, NSS and most applications and operating systems have
the behavior of importing certificates/keys before they're used. It is
the exception to use files directly. Thus it's not a surprise that
things would work this way.

I don't want to block your use case, and I can see your reasons and
policy for doing it that way, but I don't think we should make the
general user interface for certificates in GNOME work in that fashion.

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

What about PKCS#12, PKCS#7, PKCS#8, (and each one as PEM, with all the
permutations of PBKDF algorithms and so on), and all the various other
formats for certificates and keys? Even if/when openconnect gets support
for every certificate format under the sun, we should not expect a
similar feat of every process that wants to use certificates.

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

Nice. It's nice that openconnect has this. That seems well thought out.

The p11-kit rpc stuff I'm working on makes this work for PKCS#11 using
projects that haven't been as well thought out WRT to which unix
credentials they use to access authentication tokens and stuff.

I accidentally left my patch set at home (I'm at GUADEC). I was looking
forward to hacking on it. But I'll get something for people to look at
and play with soon.

> We have to support *both* modes of operation.

Again, I'm not against supporting both. I'm happy with that. This is
about the way the we build the *general user interface* in GNOME.

In fact I'm not even against the openconnect plugin being a special
case, and having more options for how use of certificates can be
configured. But in the general widgets and design, we should be
encouraging the import use case for the reasons I defined in my previous
email.

Cheers,

Stef