[Gpg4win-devel] X509 Root certificates and trusting them

[Bernhard Reiter]

Am Sonntag, 23. Mai 2010 00:58:21 schrieb Marcus Brinkmann:
> On 05/21/2010 12:03 PM, Bernhard Reiter wrote:
> > i) Place information more prominently!
> >    Like: i.1) earlier in the readme,
> >             i.2) on the website while downloading
> >             i.3.) during the installer
> > ii) Phrase instructions better at all places
> > iii) improve the error message if that condition is met to point people
> > towards the explanation.
> > iv) possibly improve the certification manager to hint towards the
> > condiation?
> >
> > Important: The recommended way must be explained and reasoned for.
> > The workaround (using allow-mark-trusted) must also be explained
> > as what it is: A workaround.
> >
> > Marcus, Emanuel, Werner, marc, can you please suggest improvements for
> > i),ii),iii), iv)?
>
> ii) should be done anyway, but will not be effective to solve this
> particular problem. 

I think it will help because currently people seem to not understand what the 
recommended way is and why this is the recommended way.

> iii) would be good to have, but may pose technical 
> challenges (for example, detecting that the problem is a firewall rather
> than a different type of network problem may be very hard, but I am not an
> expert).  And, in any case, error messages are not sufficient here, as some
> of the issues are policy issues and not error-related, so the trigger that
> causes errors to be signaled is missing.

I think there is a defect here (at least in gpgsm 2.0.14) that will 
show "certificate missing", in a missleading situation where the certificate 
itself is there, but not trusted somehow.
And the audit-log can have more extended messages, explaining more of the 
situations that could also  happening.

> i) is completely useless: Nobody 
> but me reads READMEs (that's a fact).  Messages at download and
> installation times are untimely and we don't even know if they are shown to
> the right person (or any person at all). Misdirected messages are worse
> than silence.  I feel quite strongly about this.  Software that tells me to
> do something later which could just as well be done by the software at that
> later time automatically is totally lame.

I also feel strongly about this, if the alternative is to set the workaround 
allow-mark-trusted to "true" I'd rather improve the documentation. 
And yes, documentation is getting read, if the message is very strongly placed
(and yes this obstructs the user interface somewhat, so it will be a 
compromise).

> iv) is a good compromise: It is technically trivial, but not untimely and
> can be enriched in many ways (for example by offering to automatically set
> good options for a certain use case scenario).  As a first approximation,
> one could let Kleopatra self-test for lack of allow-mark-trusted resp. lack
> of disable crl checks and pop up an explanation of these and why they might
> be useful.

I do not think this will be strong enough, the idea is when do to what.
Personally I believe we need to use all measures.

> Centrally administrated systems should be able to suppress those
> informational texts by setting some options.  It would be sufficient to
> document that in a README for administrators.

Agreed of course.
Bernhard



-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://lists.wald.intevation.org/pipermail/gpg4win-devel/attachments/20100525/ae143445/attachment.pgp