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 tokens. 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 https://bugzilla.gnome.org/show_bug.cgi?id=679860 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 key. 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 https://bug679860.bugzilla-attachments.gnome.org/attachment.cgi?id=322663 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 http://david.woodhou.se/seahorse.png 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 feedback. 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 that. 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
