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

[Christoph Anton Mitterer]

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

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


> While i suspect Kristian would be more responsible than the
> least-responsible of the parties authorized by the CA cartel, i don't
> think we want to increase that particular attack surface.
Not sure about that, but can packages that provide certs in the ca-
certificates framework select, that their certs aren't automatically
chosen?
That way, we could have it in the framework, let dirmngr pull the
package in, and still no one would be affected by it unless he chooses
to
.
> 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).


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

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


Cheers,
Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5313 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20151211/e99131f4/attachment-0001.bin>