(cc:ing Stef since this is probably going to involve gcr and gio changes)

I think we want the UI to support three possibilities (for each of "CA certificate", "User certificate", and "Private key"):

  1. Pick a file in the filesystem (and then we'll pass that filename
     to openconnect)
  2. Pick a file in the filesystem, import it into the keyring, maybe
     optionally delete the original (and then we'll pass a pkcs11 URI
     to openconnect)
  3. Pick an existing item from the user's keyring (and then we'll
     pass a pkcs11 URI to openconnect)


For #1, we need a GtkFileChooserDialog with a bit of extra smarts attached to it (eg, to validate that files are in the correct format). We have that in nm-connection-editor for WPA/802.1x, and each of the VPN plugins has a copy+paste of it, which is lame. I think we probably want to push this into libgcr. It should have a method to say what type of object you're looking for (CA / client cert / private key), and a method to say what formats you can accept (pkcs1, pkcs8, pkcs12, etc) since different external apps support different formats. And maybe it should even be able to convert between formats if needed? It would definitely be spiffy to have code to do that *somewhere*...


#2 would look mostly like #1, plus a GcrImportButton or something.


For #3, we probably want a dialog with a GcrListSelector, but we need an appropriate GcrCollection to display in it. My first thought was that we could have a GcrCollection that displays an appropriate subset of a GTlsDatabase, but there are a few problems with that. First, GTlsDatabase doesn't currently have API for iterating it. Second, and more importantly, there's technically no guarantee that the default GTlsDatabase is PKCS#11-based (and not even any way to query if it is). Do we want to say that it has to be? It seems to me that it would be really weird to have certificates that were visible to openconnect via PKCS#11 that *aren't* visible in the default GTlsDatabase. Right? So... the default GTlsDatabase is always PKCS#11-based? (Well... unless gnome-keyring isn't installed... So maybe we need some API to verify that it's PKCS#11-based and not provide the "pick from keyring" option if it's not.)

Alternatively, there could be a GcrPkcs11Collection in gcr that used PKCS#11 "directly" (via gck and p11-kit). (But it still seems like we want to say that if any pkcs11 URIs exist on the system, then the default GTlsDatabase can resolve them...)


So, how do you represent "either #1 or #2 or #3" in one (sane) UI?

Having a single button (like the GtkFileChooserButton in the current UI) is very clean-looking in the "idle" state. Maybe have a button where clicking on it could pop down a menu where you can choose "Select a file on disk..." / "Select a [certificate|key] from the keyring..." / "Import a file into the keyring...". ? And if so, does that combined button belong in libgcr too? (It seems like you'd want basically the same thing when configuring a client-cert-based account in evolution, right?)

(In reply to comment #1)
> Having a single button (like the GtkFileChooserButton in the current UI) is
> very clean-looking in the "idle" state. Maybe have a button where clicking on
> it could pop down a menu where you can choose "Select a file on disk..." /
> "Select a [certificate|key] from the keyring..." / "Import a file into the
> keyring...". ? And if so, does that combined button belong in libgcr too? (It
> seems like you'd want basically the same thing when configuring a
> client-cert-based account in evolution, right?)

Whatever we do, I think it definitely lives in gcr. There's *nothing* here that is specific to OpenConnect; there should be a widget that Just Works™.

As you say, #1 looks a lot like #2. So perhaps just the same dialog with separate 'use directly from file' and an 'import to keyring' buttons. Or a checkbox for 'Import to keyring and use from there', with a single action button.

We probably want a 'preview' window in the file dialog, with a GcrKeyWidget and/or GcrCertificateWidget.

And do we want to get the user PIN when selecting/previewing key files? I suspect so, so that we can ensure that they're valid. That gets fun for OpenConnect where we have the optional magic hack of "key passphrase is the UUID of the file system on which it was stored", which is used by $EMPLOYER to approximate the 'tied to this computer' security offered by the Windows certificate store.

I'm definitely happy to limit ourselves to PKCS#11 URIs that are configured properly (in /etc/pkcs11/modules/ or ~/.pkcs11/modules) and can be resolved by the default GTlsDatabase. Although as a prerequisite for that, we *will* also want a nice UI way for a user to add a new PKCS#11 module to their own configuration, and we'll want distros to ship with 'user-config: merge' in /etc/pkcs11/pkcs11.conf as default. But that's a separate discussion.

So I'm imagining a 'choose cert' dialog window which perhaps has tabs for 'Choose from file' for your ##1,2, vs. 'Choose from database/token' for #3. Or some other selection mechanism which makes the guts of the dialog change from a file dialog to whatever we do for #3, if you don't like tabs.

For #3 do we just use the GTlsDatabase? Or have a way to select different PKCS#11 slots from a list, and view the certificates in each one? If I plug in a USB token, I imagine the best UI for that would be to select the token from the list of slots, then choose the correct certificate from it. I don't want to even *see* all the stuff that's in gnome-keyring.

Ideally we'll also want to limit ourselves to 'certs which have matching keys', perhaps. But that's hard when we need a module PIN in order to even *see* a key...

*** This bug has been marked as a duplicate of bug 719982 ***

I'm reassigning this to GCR and reopening it to cover the (lack of) GUI widget which actually allows the user to choose a certificate/key pair. I have a GSoC candidate who is interested in working on this part.

Created attachment 322663 [details]
mockup of file/pkcs11 chooser UI

For now I am not planning to ask the GSoC candidate to cope with *importing* from files to certificates. In the first instance, the GcrCertificateChooser dialog would only support selecting certs/keys from files and/or PKCS#11.

It would look a bit like the GtkFileChooser, with additional locations for the PKCS#11 tokens available through p11-kit, something like the attached mockup.

When you've selected a PKCS#11 token in the left-hand side, the main part of the dialog (where the file list usually goes) would probably change to be a GcrTreeSelector or GcrListSelector.

If the token is locked, then as well as the little lock icon that Seahorse shows in its list of tokens, there should be an additional button at the bottom of the Gcr{Tree,List}Selector which says "Unlock token to show more...". It's more obvious for the user that way, if the object you're looking for isn't visible until the token is unlocked.

If a PKCS#12 file is chosen, the user may be asked for its passphrase.

Once the certificate is chosen, its details should be shown in a GcrCertificateWidget in the dialog box and we should next start looking for the corresponding private key....

First we check if the private key is in the *same* location (which is possible for PKCS#12 and PEM files, and also for PKCS#11). If so, we may only need to prompt for a passphrase/PIN for it (if we haven't got that already).

If the private key isn't there, then we need to continue with the file/pkcs11 chooser functionality, making it clear to the user that we are now asking them to select the *key*. Again it can come from file or PKCS#11 (independently of where the cert came from), and they might be asked for a passphrase or PIN.

When we've finally found a certificate *and* its corresponding private key, and actually *checked* that they match, we can the 'OK button will stop being greyed out, and the dialog can complete. It returns four pieces of information to its caller:
 - Private key URI (file://… or pkcs11:…)
 - Private key passphrase/PIN (if needed).
 - Certificate URI (file://… or pkcs11:…)
 - Certificate passphrase/PIN (if needed).

As a future extension, we can implement feature flags so that callers can indicate what kinds of certificate/key they can support — they may not support PKCS#12 files, or PKCS#8 files, or legacy non-PKCS#8 OpenSSL-encrypted files, or *separate* files for key+cert, or PKCS#11.

As noted, I am also prepared to leave the task of *importing* certs/keys into PKCS#11 for later. Perhaps it would be implemented by having an 'Import...' button alongside the 'OK' button. And/or renaming the 'OK' button to something like 'Use from here'. Either way, *later*.

Are there use cases where we'd want to permit selecting *just* a certificate, without corresponding private key? That's mostly for trust... and I'd really like to discourage that.

In the VPN case, I was considering *removing* the option to add a 'CA cert' for the servers. Fix your system-wide trust database if your server isn't in it. And for OpenConnect at least, the UI will pop up an untrusted certificate and allow you to manually accept it.. and then remember that decision. So I'm content with a use flow which *never* makes you add a trusted cert just for one *specific* service, and thus with a GcrCertificateChooser which isn't used for cert-only selection.

If we *do* implement cert-only selection, can we at *least* have a strongly worded note that people shouldn't be using it for that purpose; that trust should be handled differently?

Created attachment 329436 [details]
Devconf user study

(Citing an email from Nikos, to ensure this is archived)

On devconf 2016 we performed a user study on the NetworkManager
openconnect UI with the purpose of improving the network
manager VPN interface. I attach the results and some recommendations
with the purpose of improving that interface. The study, the results
and the recommendations were compiled by Lenka Horakova who specializes
in user interfaces.

Lubomir, you may want to take a look since some of the results apply to
the main interface of NetworkManager, and possibly to the other VPN
plugins of network manager.

A short summary about the tasks (see openconnect-devconf-testing.pdf):
1. Task: connect to VPN server using Username + Password
2. Task: connect to VPN server using Certificate
3. Task: Suggest mock interfaces for smart card support and check user
interaction (this is David's suggestion due to [this bug])

The 3 colored pdfs apply to the 3rd task.

Created attachment 329437 [details]
Blue study

Created attachment 329438 [details]
Green study

Created attachment 329439 [details]
Yellow study

Brief status update...

We had a GSoC project on this last year, working through the design issues and coming up with a proof-of-concept implementation at

https://github.com/tyagi-prashant/gcr/commits/master

It wasn't polished and complete enough to be merged, but it's a good start. Further development is happening at

https://github.com/NetworkManager/gcr/commits/lr/pkcs11-chooser

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gcr/-/issues/61.