[pkg-gnupg-maint] Bug#807620: 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 19:23 -0500, Daniel Kahn Gillmor wrote:
> hm, certs shipped in ca-certs are added by the system administrator,
> not
> by the user.
Sure, I meant user in contrast to Debian/package mainatiner.


> > > 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 :)
Yeah, saw it afterwards... but one can never make that "joke" (which
unfortunately is the sad reality) too often ;)


> 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.
Uhm... IMHO, Debian shouldn't make any assertion about the [not-
]trustworthiness of CAs it ships in the ca-* packages - how could it.
Take ca-certificates itself, which is, CA-wise, merely the Mozilla
bundle. Mozilla in turn can definitely be considered evil in that whole
game, they distribute CAs to their users which have already proven to
forge certs, and those which everyone knows that the people in control
of them use them for spying and attacks.

Adding another one, e.g. Kristian, doesn't really reduce security
anymore, *even* if it would be generally enabled.
But as I've said, my suggestion would be that a ca-sks-keyserver-
netwotk package simply shouldn't enable the cert per default.

Your comment about "we shouldn't make it easier for Debian users"...
well this is Debian, not Apple, Windows or Ubuntu, assuming the end-
user/admin to be dumb and trying (and usually failing) to protect him
from stupid things.


> > 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!
Uhm... what should that be good for? They secure the cert bundles via
gpg, which is probably the better way.

Apart from that, I guess we drift off into some political debate...
Take the IGTF certs... I know the guys behind IGTF (not behind each of
the bundled CAs), and I'd trust them much more than the Mozilla bundle
or cancerous things like letsencrypt.

Any of the "audits" done by the CA forum isn't worth the paper used to
print the certificate on, again as shown by many examples in the past.
And IIRC, even letsencrypt is already under criticism for de facto
breaking all the audit rules, and they just use some de-jure backdoor
to justify themselves...
And even if the audit would be done properly, what is it worth in the
end, if any NSA agent can file a national security letter + gag order
and the US based CAs need to comply.
And I guess for CNNIC and friends, their respective government agents
wouldn't even need to write a letter ;)


Long story short...
- ca-certificates is/should be the infrastructure for CAs in Debian
- The SKS CA, may be generally used (i.e. not just by gpg, but also
  browsers, lynx, wget, curl, or scripts, when interacting with
  keyservers).
  Therefore it should be shipped as part of that framework.
- The namespace problem exists for any other CAs as well.
- The other CAs are probably not much more trustworthy than Kristian
  (and likely less competent than a CA run on a normal Debian box)
- I agree, that the SKS CA shouldn't be enabled per default for users 
  (actually I think none of the ca-* packages should enable anything 
  per default).
- Requiring people to manually enable the certificate, is enough 
  protection against people shooting accidentally themselves.
  If someone does enable it and doesn't understand the consequences,
  well, that's beyond what we could or should protect such guys from.
- Shipping the cert as part of dirmngr, makes it not really usable by
  other packages or people, because this would mean they'd have to 
  install the former.
  Even if you spilt it out in a single package (outside of the
  framework), it would be a bit of a pity, as it then cannot be used
  automatically with curl/wget/etc..

Of course, you're the maintainer, and it was just a suggestion for
improvement.


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/58f54859/attachment.bin>