Usuability feedback (mainly) for KDE Kleopatra

[Bernhard Reiter]

During the fifth kdepim meeting in Osnabrück this January
I have gathered feedback about the KDE clients behavior about crypto.
Beside that a real tutorial still is missing,
the hypothesis was, that is was way to difficult to get S/MIME working
with KMail.

In the best tradition of doing real work,
we sat down and went through it. 
Here is a valuable feedback document.
I think we should try to improve the mentioned situation
and at least discuss the feedback.
Would it be good to create issues?
If so, in which tracker?

Best,
Bernhard
 
-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
Ägypten Usability.
Feedback mainly from Martin Konold during the KDEpim Osnabrück 
meeting Jan 2007. Also from Bernhard Reiter and Ingo Klöcker.

Mainly about the KDE gui, aka Kleopatra and KMail interactions.
Tested against Debian Sarge Packages (proko2 2.1.6) with LANG=de_DE at euro.

2007-01-13

Mainly about key generation and the wizard for it.

1) Screen about personal data.
	a) it misses an explanation for the "*" that some attributes have.
	   (It probably means: is MUST attribute)
	b) the CN should be explained better as it is unclear
	   that most people would enter their christian and surname
	   in there or whatever their CA's policy is.

2) Screen about "decentral key generation".
	a) "decentral" should be explained a bit further.
	b) The button that needs to be pressed before you can 
	   progress really breaks the flow. Maybe just using "next"	
	   would be better and saving one button
	c) It is odd that "back" is not allowed after key generation.
	d) The button for broken CAs leaves the user quite helpless,
		at least a tooltip is needed that gives a recommendation
		"Activate only if your CA explicitely demands this old format".

3) screen about parameters
	a) this output is useful to the common user, should be
	   in a more useful format. It is internal and better would be
	   a text representation.
	b) the Text "Bitte kontrollieren Sie das untenstehende Zertifikat"
		(please check the certificate below)
	   is missleading as the parameters do not constitute a certificate
	   not even clearly identifying one.

4) Wish: Aliases should be configured for the certificate right away.

5) During creating of the certification while three pinentry dialogs
   come up. The progresss dialog is somehow not really nice as 
   the uppopping pinentry dialogs obstruct the flow and the progress
   dialog might look stopped.

6) Unreproducable, so just report for documentation
	a) At one point we could go to the "next" without having
		filled in an email address and then we could not
		go back to change it (I do not know anymore which
		screen it was and could not reproduce.)
7) Strange
	dirmngr started when sending of the request to ca at intevation.de.
	No idea why as the email itself was not signed nor encrypted
	nor anything, just the smime.p10 attachment.
 
	

2007-01-014


i) Wish: Importing keys should get a more detailed output.
  It is true that sometimes it is not clear what was imported.

ii) Kleopatra: When selecting a range of keys and doing a "validation"
    the text in the lower status bar says "Schlüssel holen ..." (Fetching
    keys...) This is missleading as there is no key fetched usually as 
    far as I know, but the keychain is evaluated and the crls downloaded
    if necessary.

iii) Configuration dirmngr: Some of those options should be rephrased
	positively, aka "allow LDAP" instead of "inhibit the use of LDAP".
	and then of course the default be marked. 

iv) Display of date. In German locale, some dates were still displayed
   	in the iso format aka 2006-12-24, this should be localised.
	a) in the passphrase dialog for openpgp: please enter..
	"erzeugt 2006-12-24", should be "erzeut 24.12.2006".
	b) in the message heads.
	  a test with the version
		Kontact: 1.0 (proko2 branch after 2.1.6),  Revision 645321.
		Debian Sarge (ppc) with KDE: 3.3.2 Qt: 3.3.4
	  shows that the date is okay, but it reads in S/MIME as
		Die Nachricht wurde von CN=Bernhard Reiter,O=Intevation GmbH,C=DE auf 02.03.2007 14:29 mit dem Schlüssel 0x8749F05371C3410C signiert.
		it should be "am 02.03.2007"

v) Display of received signed smime email: When the email address deviates
   from the one in the certificate
   a) "Achtung: Die E-Mail-Adresse des Absenders wurde nicht in dem certificate gespeichert," [..]   "certificate" should be translated.
   b) The message is green, though it contains a warning "Attention:".
      Maybe we could make this part of the message colored differently
      so the warning can be seen more clearly. I am suggesting a colored
      frame around the warning, but inside the green frame,
      because after all you are trusting the key.

vi) KMail, Display of received smime email: It always says "message"
	while it sometimes actually is a message part.
	Example: send an email, attach two files and only sign
	the second one (but not the total email).
	The resulting email has one signed message part in the middle,
	but this one is green and its frame has "signed Message" in it.
	Should be "message part".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1310 bytes
Desc: not available
Url : /pipermail/attachments/20070402/fabe5ad7/attachment-0001.bin