Design help requested: Certificate Chooser UI.

Tyagi is working on a GSoC project this year, implementing a
certificate chooser which will probably live in the GCR library.

We currently have a variety of incomplete and buggy implementations of
this, spread across various places; especially NetworkManager UIs and
the VPN plugins. All of them get *something* wrong — not implementing
support for certain types of certificate/key file, or not supporting
PKCS#11 for access to objects in gnome-keyring and hardware crypto

The point of the project is to have a consistent UI for choosing a
certificate (and corresponding private key), which everyone can use.

This is

The "output" from such a widget would be four things:
  • Certificate location (file:… or pkcs11:…)
  • Passphrase or PIN for certificate, if necessary.
  • Key location (file:… or pkcs11:…)
  • Passphrase or PIN for private key, if necessary.

In some cases the certificate and key are found in the *same* location
(in the same file, or referenced by the same PKCS#11 URI). In some
cases there may not be a passphrase or PIN. In rare cases, you might
need different passphrase/PIN to access each of the certificate and the

The overall UI flow of the certificate chooser probably ends up looking
something like...

 • Select certificate (from file or pkcs11)
 • If PIN/passphrase required, ask for it.
 • If key in same location, display 'preview' and activate 'OK' button
 • If no key, select key (from file or pkcs11)
 • If PIN/passphrase required for key, ask for it.

Once the certificate and key are both found and unlocked, we can do a
crypto operation to check that they *match*, display the details of the
cert/key, and allow the user to click 'OK'.

There's scope for UI designers to improve that overall process, and
feedback would be welcomed. Note that the above description slightly
glosses over some of the details about precisely what the various file
formats can support and *when* the PIN is needed.

But the most important thing right now, I suspect, is the thing that
crops up twice in the above:

 • select <thing> from file or pkcs11.

We had an intern at Red Hat do some user interaction tests¹, and the
favoured model looked like the mockup shown at
Basically, the available PKCS#11 tokens are shown as 'locations' in
what otherwise looks like a file chooser dialog. But when those
locations are selected, you end up with an inner widget (in the
GtkFileChooserDialog's "browse_files_stack") that lists objects in a
PKCS#11 token instead of files in a directory — modelled more on the
Seahorse UI as seen at

From the purely UI point of view this seems (to me) to be ideal —
presenting the available PKCS#11 tokens as "locations" makes sense, and
seems like the better user experience.

However, it's apparently a pain to implement, and requires extensions
to the GtkFileChooserDialog that don't make people happy.

I'm reluctant to implement a top-level choice, *first* forcing the user
to choose between file and PKCS#11, and then having a list of file-
locations vs. a list of pkcs11-locations depending on that first
choice. I just don't like that from the UI point of view, although I
appreciate that there's a trade-off between UI and ease of
implementation, and also that I'm not the person to be having strong
opinions on UI design... which is precisely why I'm here asking for

I think we *could* make the model in the mockup work; we might even be
able to do a nasty trick with a GtkStack which has one child which is a
GtkFileChooser and another child which is a widget of our own design
which just happens to *look* like the surroundings of a GtkFileChooser
(the locations bar on the left, and our own PKCS#11-selector in the
main area). We'd mirror the contents of the location ("shortcut"?) list
in both widgets... and when a PKCS#11 location is chosen we'd flip the
outer stack to display our own one, and when a file location is chosen
we'd flip to display the real file chooser instead.

That's a vile plan, of course; it does seem like there should be nicer
ways to enable this use case in GtkFileChooser. Perhaps by allowing the
caller to register a URI "scheme" handler so that when a location with
a matching (e.g. 'pkcs11') URI scheme is selected, the appropriate
callback occurs and our own widget is put into the browse_files_stack.

Or instead of a scheme handler, perhaps a variant
of gtk_file_chooser_add_shortcut_folder_uri() which also takes a
callback to *create* the widget. You might use that approach to also
clean up the special-case for things like 'Other Locations', allowing
that to be provided as the same kind of 'plugin' instead of special-
cased as it is now.

Alternatively... is there a better UI design that doesn't lead to us
asking such questions at all? Suggestions are most welcome. As noted,
I'm not really keen on "choose file vs. pkcs#11 first". But if we
really can't come up with anything better, I suppose we can tolerate

Fundamentally, all we *really* care about is that there should be a
coherent UI for everywhere that we want users to select their personal
certificates, and that it should support all the various file types as
well as PKCS#11. We'd like the user experience to be as good as
possible, of course, but in some ways that can be improved later and is
secondary to the "what API does the GcrCertificateChooser offer to its
users" question, and to making those potential users actually *use* it.

Thanks for reading this far, and for any feedback you can offer!

David Woodhouse                            Open Source Technology Centre
David Woodhouse intel com                              Intel Corporation

¹ Nikos, the reports were only sent in private email, is it OK to   attach the PDFs to the GNOME bug please?

Attachment: smime.p7s
Description: S/MIME cryptographic signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]