On January 11, 2018 11:28:08 PM GMT+01:00, Moritz Wirth <m...@flanga.io> wrote: >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
A misissued cert could still be used if attacker is persistent enough. Either through dns poision or other attack vectors. And yes, I only issue certs to servers I recognize to have been in the pool for a while and operator should be in the openpgp wot strong-set. -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP certificate at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel