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: Kristian Fiskerstrand
Subject: Re: [Sks-devel] Unde(r)served HKPS [was: Underserved areas?]
Date: Fri, 12 Jan 2018 00:43:20 +0100
User-agent: K-9 Mail for Android

On January 11, 2018 11:28:08 PM GMT+01:00, Moritz Wirth <address@hidden> 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
>> address@hidden
>> 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



reply via email to

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