2.1.14 -- dropping qualified.txt and com-certs.pem

Werner Koch wk at gnupg.org
Fri Jul 15 11:43:59 CEST 2016

On Fri, 15 Jul 2016 03:39, dkg at fifthhorseman.net said:

> The result is that a "make install" ends up not shipping either
> /usr/share/gnupg/com-certs.pem or /usr/share/gnupg/qualified.txt


For com-certs.pem.  We don't want to decide which root CAs are good (if
there are any at all).  In the pas ca-cert was distributed to give it a
push but cacert never took off except for geeks.  Well, there is one
exception: the certifciate for sks-keyservers.net.

The qualified.txt had only expired certificates and was thus useless.
Also the rules for qualified signatures changes a a couple of years ago.
It is not anymore possible to have a definitive list of root
certificates to indicate a certificate used for qualified signatures.
That whole qualified signature system is FUBAR.

> authority's certificate instead?  If not, how will users know how to
> validate LE-signed sites?

dirmngr uses the system provided certificates.

> As a distributor, i'd like to ship documentation that matches what's
> installed.  I see four options for the debian packaging:
>  0) clean up the info/man pages to not claim that any of these files will
>     be installed.

Okay, will do.

>  1) go ahead and keep shipping the files from the source repo (they're
>     still present) even though they aren't installed by "make install"

Isn't this a task for Debian's voliatile repo?

>  2) decide on some new CAs to trust, write our own qualified.txt file,
>     and install them both.

See above.

>  3) point to other CA lists already installed by the OS, and generate
>     qualified.txt from the same sort of system-level defaults (i don't
>     know how to do this right now)

See above



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */

More information about the Gnupg-devel mailing list