On Thu, 2016-05-12 at 12:47 +0530, prashant iiith wrote:
Hi david, I was trying to implement the workflow for certificates from files, do we have any case other than .p12 files in which certificate is protected by pin or passphrases.
Hi Tyagi,
I've replied on desktop-devel-list because this touches on the design
issues that I glossed over yesterday (I was *trying* to keep that mail
short, by focusing on the {file,pkcs11}-chooser requirement which comes
up twice in the overall flow)
We have a number of sources of the certs/keys we need:
• .p12/.pfx (PKCS#12) files are password-protected, and will
typically contain *both* the certificate and the key we need.
• PKCS#11 modules (like gnome-keyring and other hardware and software
tokens) can contain both certificates and keys. You may need to log
in to a PKCS#11 token with a PIN before you can even list the
objects therein — including certificates, which answers your
question above. Or maybe you can see certs but not keys until
you log in. Or maybe you can *see* keys but not *use* them.
• .pem files of various kinds. These contain base64 data labelled with
tags like '-----BEGIN PRIVATE KEY-----' and a given file can contain
many things. Certificates in this form will be unencrypted, and won't
need a password. Keys might (and often well) be encrypted. And might be
in the *same* file as the cert, or might be in a different file.
Here's where we really want the UI experts to help us...
I wonder if it's best to think of the overall workflow for this
'GCRCertificateChooser' as a CertificateWizard. You first select the
certificate, and then (if necessary) you select the matching private
key. With a 'back' button to go back and change the certificate, etc.
Let's set aside the question of how you present the file vs. pkcs11
option to the user, since we're (hopefully) discussing that in a
separate thread.
In the case of a *file*, the first "Select Certificate" page of the
wizard basically wants to be a GtkFileChooser, with a preview widget
which is something like a GcrCertificateWidget.
If the user selects a PKCS#12 file which needs a password... either we
have a pop-up dialog, and then we can show the preview and wait for the
'OK' button. Or we make them click 'OK' (or is it 'Next'?) without a
preview, since we can't decrypt the file yet, and demand a password on
the next page? Again, opinions from people who are actually *qualified*
to have opinions would be welcome...
If we're choosing a cert from PKCS#11, refer to the screenshot at
http://david.woodhou.se/seahorse-preview.png — if you squint hard, it
looks a bit like a GtkFileChooser in its layout — locations on the
left, the main object list in the middle, and a preview on the right.
We should make ours like *exactly* the same, I think.
The difference here is that PKCS#11 tokens might need to be unlocked
before you can see the certificate you want — and when it's unlocked
you might see *some* certificates, but not all.
I don't like the Seahorse model for representing this, with the little
padlock icon on the token on the left, and needing to right-click and
unlock it. Users are just going to see that the certificate list
doesn't include the one they want, and they *aren't* going to find
that. I think that we want to add an "unlock me to see more" to the
main certificate list (in the middle panel). And when clicked, we
prompt for a PIN to unlock the token.
So... once we have a certificate, we *might* be done. If it's a PKCS#12
file with the key inside, or a PKCS#11 location and we find the key
right next to it as it "should" be. And we can jump straight to the
final confirmation page of the wizard, displaying the cert details
(much like the preview), and a 'Finish' button.
Or we aren't done, and we need to go looking for the key elsewhere. The next page of the wizard is the key
selection, which basically looks the same as the certificate selection — and even all the passphrase/PIN
requirements are basically the same. Only the preview is different. At this point we need to do a
cryptographic check to see that the key really does match the certificate — you can't choose cert+key that
don't match. So maybe we use the 'preview' area to display that — if you select a mismatching key, the
preview says "This key does not match the certificate", and the OK/Next button is greyed out.
The other possibility, after selecting the cert, is that we're *almost*
done... if the cert was in a PEM file which also contained an encrypted
key, all we need now is the *passphrase* for that key. Likewise, it's
possible that the certificate was found in PKCS#11 without unlocking
the token, but we can't see the *key* until we log in, even though it's
right there in the "expected" place alongside the cert.
How we handle that depends on how we handle the passphrase/PIN
requests. If it's pop-up, I suppose we do that. If it's an input
request *within* the dialog, which I think I'd prefer, then I think our
'almost done' flows should jump into the key-selection page of the
wizard, with the appropriate file already selected and asking for its
passphrase. Or for PKCS#11, as if the 'unlock me' button has been
pressed, and asking for the PIN. And *then* automatically selecting the
key in question, if we find it there. Or leaving the user to go
navigating to find a key, if not. But again, UX input most welcome...
--
David Woodhouse Open Source Technology Centre
David Woodhouse intel com Intel Corporation
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
