sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] Unde(r)served HKPS [was: Underserved areas?]


From: Moritz Wirth
Subject: Re: [Sks-devel] Unde(r)served HKPS [was: Underserved areas?]
Date: Thu, 11 Jan 2018 23:28:08 +0100

I requested a certificate a few days ago, however only well known keyservers receive a cert for HKPS (which is reasonable because the certificates are valid for a year and there is no reliable way for certificate revocation).

Another idea around the mitm problem - the client retrieves the current list of servers in the pool, looks up their hostnames from the sks-keyservers.net website (or somewhere else) and connects to the server using the hostname, not the pool adress - Therefore, you would not need additional names in the certificates and it would be easy for operators to obtain own certificates. Malicious servers can be avoided easily by kicking them out of the pool dns and the certificate itself is useless as it only secures the own hostname.

Best regards,

Moritz

Am 11.01.18 um 22:30 schrieb Alain Wolf:

On 11.01.2018 18:16, Alain Wolf wrote:
Opinions, ideas anyone?

Maybe something along the line of ...

1) Server operator puts his PGP fingerprint in the servers contact
information (as we do today but would need to be mandatory HKPS).

2) Server operator creates server private key and CSR.

3) Server operator stores CSR on the server in something like
./well_known/hkps/0x27a69fc9a1744242.csr

3) Server operator signs the CSR with his PGP key and puts the signature
in ./well_known/hkps/0x27a69fc9a1744242.csr.asc

4) Kristian's hourly checking script does the usual tests but
additionally tries to fetch the CSR from its .well-known location.
Checks if the PGP signature of the CSR was done with the key who's
fingerprint is in the servers contact information.

5) The script signs the CSR with the CA key and sends the signed cert to
the server operator in a PGP encrypted mail.

6) Server operator installs the signed cert on his server.

7) The checking script could do some HKPS checks. Valid certificate? Not
expired? Deprecated ciphers? Perfect forward-secrecy? etc.
If everything checks-out server is added to hkps.pool (This might
already be the case today)

Cert expiry could be 3 months, checking script removes any server from
the pool who's cert expires in the next 24 or 48 hours. Cert should not
be valid longer then the operators PGP key.

For certificates renewals, the process could be the same, a new
certificate is issued as soon as the checking script finds a new CSR (or
the same CSR but a new PGP signature along with it).

Server cert revocations could be requested manually by asking the CA
operator or automatically by placing a PGP signed
0x27a69fc9a1744242.revoke.asc file in to the .well-known directory.

Revocation or expiry of the servers operators PGP key, should lead
automatically to the revocation of the server cert and removal of the
server from the pool.

After a while this could be made mandatory. So 100% of the sks-pool
servers are also in the hkps.pool

Creation of server keys, CSR and PGP signing could be automated (or
partly automated because of the PGP signing) by scripts distributed with
the SKS software package.

I don't think I am really qualified for designing new security
protocols, but the idea doesn't go out of my head. Sorry for the long post.

Regards

Alain



_______________________________________________
Sks-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/sks-devel


reply via email to

[Prev in Thread] Current Thread [Next in Thread]