[Gpg4win-devel] X509 Root certificates and trusting them

[Bernhard Reiter]

Am Mittwoch, 22. September 2010 10:01:13 schrieb Bernhard Reiter:
> Am Freitag, 21. Mai 2010 12:03:22 schrieb Bernhard Reiter:
> > The recommended way for a
> > production X509 /CMS system is that a list of trusted X509 root
> > certificates is maintained by the administrator of the system
> > directly for dirmngr and possibly the global gpgsm.
>
> For gpgsm to be able to use certificates,
> you need to have the full validated chain of certificates.
>
> [Forth edition]
>
> Especially for the root certificate, the person administrating
> the machines (e.g. you) must ensure four conditions are given.
> (Paths examples are for GNU systems,
> the paths will be different for Mac OS or Windows.)
>
> a) You need to have the root certificate and be sure that the file you have
>    is really the root certificate you would like to trust. You need to do
> this best at installation time, because later - in the heat of the moment -
> users will go along with everthing unchecked just to get the task done.
>
> b.1) Make sure dirmngr trusts the root certificate.
>    info dirmngr Installation
>    konqueror info:/dirmngr/Installation
>    http://gnupg.org/documentation/manuals/dirmngr/Installation.html
>
>    In short, recommended is to use the system dirmngr,
>    place the root certification file in .der format
>    in /etc/dirmngr/trusted-certs and restart the dirmngr service.
>
> b.2) Current revocation status information must be available.
>    gpgsm will ask dirmngr to validate each certificate.
>    As administrator you need to make sure that dirmngr can do that check.
>
>    Usually certificates contain information where to get the revocation
> list via http or ldap. So dirmngr should be able to do http and ldap calls
> to the internet. Secure connections are not necessary as revocation info is
> already signed.
>
>    You can tune dirmngr to use proxies or always ask specific servers
>    via ldap. There are a number of other ways, like OCSP, to get revocation
>    information. Too much to list them here. With sane certificate
> authorities and network settings it will just work with the revocation
> lists out of the box.
>
>    If you need to trouble shoot, you can turn off checking of revocation
>    information for a moment to verify that this is the problem. Leaving
> this off for production will degrade security significantly.
>
>    Users should have "prefer-system-dirmngr" in their local
>    gpgsm.conf (Usually ~/.gnupg/gpgsm.conf).
>    So that the system dirmngr is asked all the time.

Using the system dirmngr has the advantage that central administration
can approve root certificates for the most common communication partners
of the organisation. IT-Administration should do this in my view.

In addition for extra comfort of the users I believe that
well used intermediate certificates should be added to 
   /var/lib/dirmngr/extra-certs/
and that common directories services should be configured in
  vim /etc/dirmngr/ldapservers.conf 

(Don't forget to kick dirmngr after a change in configuration, e.g.
by restarting the service.)

>
> c) Make sure gpg-agent trusts the root certificate
>    Recommended way is to do this system wide:
>    c.1) Place the right line in /etc/gnupg/trustlist.txt
>
>    Note that quite a few certificate authorities need the "relax" option
>    because they fail to get some requirements right. So test everything
> later and if it does not work, try with "relax".
>
>    References:
>      Existence of configuration file:
>        info gnupg2 Installation
>        konqueror info:/gnupg2/Installation
>        http://gnupg.org/documentation/manuals/gnupg/Installation.html
>
>      Format of trustlist.txt:
>       info gnupg2 "Invoking GPG-AGENT" "Agent Configuration"
>       konqueror info:/gnupg2/Agent Configuration
>       http://gnupg.org/documentation/manuals/gnupg/Agent-Configuration.html
>
>    c.2) Make sure all users either
>         * have no personal trustlist.txt or
>         * have the option "include-default" in it.
>         The file will usually searched at ~/.gnupg/trustlist.txt.
>
> I guess all gpg-agents will need a kick after the trustlist.txt change.
> Try sending a SIGHUP to all gpg-agent processes, e.g.
>   pkill -SIGHUP gpg-agent
> or reboot.
>
> In general: If you wish to update all users' private configuration files,
> you can try using Gnupg's helper application called
>   applygnupgdefaults
> Documentation starts here:
>   info gnupg2 "Helper Tools" applygnupgdefaults
>   konqueror info:/gnupg2/applygnupgdefaults
>   http://gnupg.org/documentation/manuals/gnupg/applygnupgdefaults.html
>
> Hints for reading the documentation:
> Using the documentation of your installed version is preferred,
> because it usually is most correct.
>
> Use "info" on the commandline, if you are familiar with it.
> It will be installed on many GNU systems. There are other exotic texinfo
> console viewers of course like tkman or pinfo.
>
> If you have konqueror installed using "info:gnupg2" as URL will also work.
> Konqueror internally uses the script /usr/share/apps/kio_info/kde-info2html
> which on Debian Lenny comes with the kdebase-kio-plugins package.
> This is my prefered method.
>
> Best,
> Bernhard


-- 
Managing Director + Owner: www.Intevation.net <- A Free Software Company
Kolabsys.com: Board Member          FSFE.org: Founding GA Member
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: smime.p7s
Type: application/pkcs7-signature
Size: 3694 bytes
Desc: not available
URL: </pipermail/attachments/20110622/259f484f/attachment.bin>