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 > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
