[pkg-gnupg-maint] Bug#807620: Bug#807620: Bug#807620: dirmngr: split SKS keyserver network CA into separate ca-certificates compatible package

[Daniel Kahn Gillmor]

On Thu 2015-12-10 19:08:03 -0500, Christoph Anton Mitterer wrote:
> On Thu, 2015-12-10 at 18:51 -0500, Daniel Kahn Gillmor wrote:
>> I don't think that the sks keyserver network CA should be in the
>> general
>> ca-certificates framework, because it isn't properly name
>> constrained.
> It would be still upon the user to select the certificate...

hm, certs shipped in ca-certs are added by the system administrator, not
by the user.

>> adding it to ca-certificates would allow Kristian the ability to MITM
>> most TLS connections.
> to be honest, I think Kristian is probably a thousand times more
> trustworthy, than CNNIC, TURKTURST*, WooSign, and likely a quarter of
> the other Mozilla-Bundle CAs...

i made that joke already :)

>> i don't know anyone who uses it for the web interface, and i suspect
>> that using it there would be problematic for the non-name-constrained
>> reason described above.
> uhm... I have it in place for the webinterface... and out of 6 servers
> from the sks status page that have hkps, 5 used the SKS keyserver net
> CA for https, and the 6th redirected and https to http (o.O)... so I'd
> rather guess that anyone uses it like that (which seems to be natural).

Please report the 6th as a bug to Kristian!  The fact that you're
willing to open your TLS authentication for any arbitrary network
service to Kristian's authority doesn't suggest that we should make that
easier in general for all debian users, though.  We ship the cert
already in dirmngr.  If people want to point their browsers (or other
tools) to it, they can do so.  But i don't think we should ship it with
other general purpose CAs.

> Anyway, I think the ca-certificate framework makes only sense,
> respectively has the rationale that in principle any CA cert that is
> shipped in Debian can be managed as part of it.

But this makes sense for specific CAs that we know to work for every
zone.  Kristian's CA *isn't* supposed to work for every zone, but it
doesn't contain any guidance to interpreters of that storage that it
shouldn't be used anywhere else.

> I agree, that there are cases where such cert shouldn't get
> automatically enabled, just by installing it (e.g. in our case here),
> but if this cannot be done already, then it's rather simply a feature-
> bug in the framework that needs to be solved.

The feature-bug(?) in ca-certificates that would need to be fixed to for
me to start to consider this as a possibility would be to offer a way
for CAs to be effectively name-constrained.

> Also, we already have non-general-use CA packages in the framework (see
> igtf*).

yow, those are not packages i'd be very comfortable maintaining without
a heavy audit.  I'm a little surprised that the Homepage: of that
package itself doesn't even seem to be listed with https!

Regards,

        --dkg