Re: [Sks-devel] Setting up hkps

[Phil Pennock]

On 2013-11-12 at 13:54 +0400, Dmitry Yu Okunev (pks.mephi.ru) wrote:
> Hello.
> 
> On 11/12/2013 01:29 PM, David Benfell wrote:
> > On Tue, 2013-11-12 at 10:16 +0100, Filip Stefaniak wrote:
> >> 1) Do I need a "real" certificate (bought CAs) or can be it
> >> self-generated, self-signed certificate?
> > 
> > You send a certificate request to Kristian Fiskerstrand. He's running
> > his own certificate authority for this purpose and will generate a
> > certificate from your request.
> 
> Good news. However is there essential reason why Kristian's CA better
> than "cacert.org"'s?

Yes: we're abusing the whole purpose of CAs, ensuring that anyone who
can run a keyserver competently can claim to be one common shared
hostname.

Any real CA will scream and block that.

Note: you can and should set up TLS SNI support in your webserver to be
able to use different certs for different hostnames.  So for your _own_
hostname, you use a cert from as real a CA as you want.

Kristian's CA is entirely around whether or not, when asked to present
credentials for the hostname "hkps.pool.sks-keyservers.net", you will be
able to do so.

So <https://sks.spodhuis.org/> has a cert from my own CA, because that's
all I care about for that hostname.  When that same host is accessed
with a hostname pool.sks-keyservers.net or *.pool.sks-keyservers.net
then I present a certificate from Kristian.  I can do similarly for
other hostnames.

Absent DNSSEC, the client can't chain hostnames to ask for a cert from
the "real" final hostname, so each extra hostname to be supported needs
a key.

*But*: stop and ask what you're protecting against.  This is public
data, so the only thing to be protected is against tampering or traffic
analysis.  In both cases, you don't know who is running the keyserver
if you use a pool hostname, so you have no protection from https.

Kristian's PKI for this is a decent experiment and a good way of making
sure we all know _how_ to run HKPS, and helping to make sure there's a
common baseline for making sure client tools work.  It's *not* a good
"real solution for production usage".  For that, you should use your own
server, accessed under your own hostname, with a certificate from an
authority you trust locally.

(See also: an article on PGP by me in December's ;login: magazine)

-Phil

pgp2mtzq3Lndz.pgp
Description: PGP signature