Hi Daniel.

May I suggest, that the SKS keyserver network CA cert is
split into it's own package that would integrate into the
ca-certificates framework.
An example would be the ca-cacert package.

Given that the SKS keyserver network CA will be typically used for
the webinterface of the keyservers as well, some people may
want to have it generally available.


Cheers,
Chris.

Hi Christoph--

thanks for the suggestion!
ca-certificates framework, because it isn't properly name constrained.

adding it to ca-certificates would allow Kristian the ability to MITM
most TLS connections.

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.

However, i agree with you that we should ship the sks keyserver CA in a
known place so that tools that are deliberately trying to talk to
hkps://hkps.pool.sks-keyservers.net will have an easy time verifying it.

This part is already done: dirmngr ships the CA at:

 /usr/share/dirmngr/sks-keyservers.netCA.pem

You can think of this as a crufty "DLV" (domain lookaside validation)
for this one particular point in the DNS, i guess.

I'm working on a patch for GnuPG that should make it automatically use
this file as a cert if the user is visiting the hkps pool.

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.

It would be still upon the user to select the certificate...
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...
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
.
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.

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

i made that joke already :)

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.

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.

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.

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,

Sure, I meant user in contrast to Debian/package mainatiner.
Yeah, saw it afterwards... but one can never make that "joke" (which
unfortunately is the sad reality) too often ;)
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.
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.