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

[Andre Heinecke]

Hi,

On Friday 15 July 2016 03:39:37 Daniel Kahn Gillmor wrote:
> hi GnuPG folks--
> 
> in 2.1.14, c19b2061274cd50838e62a2acbdc7e7d24888e7e says:
> 
>    sm: Do not install cacert and other root certificates.
...
> The result is that a "make install" ends up not shipping either
> /usr/share/gnupg/com-certs.pem or /usr/share/gnupg/qualified.txt

I requested the removal because now that Gpg4win uses the "official" 2.1 
installer internally we ended up importing these certificates and on the first 
Launch of Kleopatra users would have been asked if they should be trusted 
(allow-mark-trusted) which was bad. They also showed up as the only two 
certificates available after a fresh install which was also weird.
(Same also happend on GNU/Linux of course)

> The justification about Let's Encrypt covers CA Cert, but moving these
> files to not be installed by "make install" seems like it also has an
> effect on the STEED "nonthority" and on the list of qualified German
> network authorities -- do you envision Let's Encrypt taking over both of
> those roles as well?  Also, should GnuPG ship the Let's Encrypt
> authority's certificate instead?  If not, how will users know how to
> validate LE-signed sites?

My opinion is that Let's encrypt should have nothing to do with the removal. 
GnuPG should not be distributing "Trust" (apart from the release keys gnupg 
also controls to verify update integrity). CA trust should be set up by the 
Administrator as it's mostly an organisation policy thing.

> Moreover, the info for gpgsm in 2.1.14 still implies that GnuPG ships
> both files.

That should probably be fixed.

> 
> 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.

Yes, that would probably be best.

>  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"

Imo they should be removed from the repo, too.

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

In that case they should be more appropiately be written down in the 
trustlist.txt and provided through dirmngr's extra-certs / trusted-certs 
mechanismn.

This means they will be avilable and trusted if needed but won't show up in 
the keyring of the user unless they are needed. This is how we are set up at 
my Company so that the German PKI infrastructure is available if neccessary 
but does not show up by default.

Afaik Qualified is just some extra thingy that is afaik not much used in 
practice.  It only marks that signatures verified by one of these chains have a 
special marker. (But I could be wrong)
As this doesn't imply trust but only provides some extra information about 
legality of Signatures in some countries I'm ok with distributing it. But the 
current list is completely outdated (afaik there is not one valid certificate 
in there anymore) so better to remove it if it is unmaintained.
 
>  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)

I would also be against this. For Windows it would mean to integrate 
with the Windows system store but that means that you will have > 100 Root 
CA's trusted for signatures and users may wish to keep that number much lower. 
Eg. only CA's that the Administrators have checked.

> What do you think distros should do with this situation?

Don't install any certificates but have nice documentation how to set up a Root 
CA base for System Administrators :-)


Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160715/dc12757d/attachment.sig>