[Gpg4win-devel] ImprovingSecurity in the Future, Discuss

Bernhard Reiter bernhard at intevation.de
Fri Jun 6 12:42:12 CEST 2014


Gerard,

thanks for your feedback and for allowing me to respond in public:

On Thursday 05 June 2014 at 13:13:01, Gerard Ashton wrote:
> To gain grass-roots acceptance the programs 

This aims at a slightly different direction to what
I was thinking off whem starting the discussion.
So I've tried to clarify a bit at
 http://wiki.gnupg.org/Gpg4win/ImprovingSecurity

Your points are important as well:

> need vastly better error 
> reporting, so the exact cause of failures can be identified by
> non-developers. 

Yes, this is a long standing issue and probably will not go away soon.
My understanding of the challenge is that ideally we bring in 
an expert system that teaches the basics of cryptography while 
support the user to perform it in the least intrusive way.
It is a lot of work, because it needs many rounds of 
design -> implement -> measure performance/observe usability -> (design)

The last major usability overhaul was started more than 5 years ago,
and we never secured enough resources to do the next design -> implement
steps from what we have learned. Technically (its the development list you've 
replied to after all ;) ) the gpgsm introduced
an audit log/trail, which is a precondition for being able to transport
problems in the backend to the frontend in order to display them
properly to users. This still is pending for being completed for gpg itself
and then it would need much more improved messages.

More interface have to use the possibilities that are already there to provide 
a nice interaction to the users. This includes using gpgme and e.g. the audit 
log and the ui server factility. Many application still do not use gpgme 
making it much harder to get detailed messages to the user. (I hope that 
http://wiki.gnupg.org/APIs and its strong recommendation for gpgme helps in 
the mid run.)

The idea of the ui server is that the hard part of selecting recipient
can be provided from a central place and used from all applications using the 
crypto backend. So we would need to improve the current ui servers (kleo, 
gpa) e.g. by 
http://wiki.gnupg.org/Gpg4win/Wishlist#Better_certificate_selection_dialog
and then make more applications use them.

> Also, there is considerable variation in X.509 
> certificates. There should never be silent rejection of such certificates
> because, in the opinion of the developers, the security choices of the
> certificate issuers weren't good enough. Rather, an understandable
> mechanism should be provided to installers or users to decide whether
> readable certificates should be accepted or not.

Agreed. When implementing it, Werner paid attention to a number of relevant 
standards of course trying to write strictly standard, but reading with 
tolerance. The various standards are thick, it would need more than one real 
expert[tm] to explain their niches and arcs. It is very hard to implement
and the current implementation in GnuPG is also hard to configure, 
unfortunately. (Hope that http://wiki.gnupg.org/X.509 helps, it already shows 
a number of basic checks and methods to diagnose what is going on.)

> Once such improvements are in place for existing functionality, 
> further security enhancements that fit in with the proper error-reporting
> and user-security-decision regime can be made.

For us the hard part is: Where is the weakest link? Of course the Gpg4win 
initiative must keep the whole border in sight and always fix the weakest 
part of the fence next. My particular feeling is that a lot of status 
reporting is already done in the backend and intermediate software product
and now the wirering must be done to the front end applications.
Outlook and Windows is of extra difficulty, because some appication aspects
are out of reach for all developers except Microsoft. ;)

Best Regards,
Bernhard


-- 
www.intevation.de/~bernhard (CEO)    www.fsfe.org (Founding GA Member)
Intevation GmbH, Osnabrück, Germany; Amtsgericht Osnabrück, HRB 18998
Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.wald.intevation.org/pipermail/gpg4win-devel/attachments/20140606/754bd7a8/attachment.sig>


More information about the Gpg4win-devel mailing list