[PATCH 2/3] dirmngr: add system CAs if no hkp-cacert is given
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Mon Oct 31 15:30:47 CET 2016
On Thu 2016-10-27 18:59:03 -0400, Kristian Fiskerstrand wrote:
> On 10/28/2016 12:30 AM, Daniel Kahn Gillmor wrote:
>> * dirmngr/dirmngr.c (http_session_new): if the user isn't talking to
>> the HKPS pool, and they have not specified any hkp-cacert, then we
>> should default to the system CAs, rather than nothing.
>> * doc/dirmngr.texi: document choice of CAs.
> I'm a bit ambiguous about this change. In Gentoo we currently have the
> use of a system CA behind a user-selectable use flag for hkps but even
> so the set of provided CAs is originating mostly from Mozilla.
> As seen with the latest WoSign / StartCom issues, mozilla is not overly
> concerned about third-party usage of the provided CA certificates, and
> have more complex restrictions in place for NSS (e.g specific
> notBeforeDate and OneCRL checking).
> As such I question the security of the root stores and actually like
> that it defaults to not using system CAs so users needs to make an
> informed decision.
We're talking about case (b) from the commit message, right?
that doesn't work for anyone right now.
In practice, most users start in case (a), with no transport
confidentiality or integrity at all. Those who manage to make it to
case (c) today are in two cases:
0) someone who has one particular server that they want to connect to,
and they have been fed their configuration by the administrator of
that server, or
1) someone who wants to use a particular server, and they have fished
around enough to figure out "where does my operating system store
the standard certificate bundle".
Some proportion of those who wish they were in in group (1) never figure
out the answer to that question, and they fall back to cleartext,
The folks in group (1) (and those who never made it to group (1) are
really better-served by us using the system trust by default, rather
than forcing them to do so manually. The change proposed doesn't affect
those in group (0) at all.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 930 bytes
Desc: not available
More information about the Gnupg-devel