Include security concerns on website

[hackergrrl]

This issue is to track security concerns about pgp.asc's key distribution model. The pgp.asc website doesn't actually talk about the weaknesses of the model, and even goes as far as to say "absolutely guarantees authenticity", which is a very dangerous claim to make. Let's figure out its weaknesses and inform users accordingly.

[hackergrrl]

Key Revocation: key servers provide a place to upload key revocation certificates, which let other users know a key is no longer valid. By centralizing a user's public key to a single location (their website), other users would still need to rely on key servers to check for revocations.

HTTP (sans HTTPS): nothing technically prevents users from using HTTP to serve their public key, or from requesters to ask for the HTTP instead of HTTPS version. This requires intent and domain knowledge on the website operator's behalf to make sure that 1. HTTPS is available, and 2. the pubkey cannot be requested with plain HTTP.

[iamwebrocker]

hi, thanks for pointing out these issues. I think the first, hm, reflex, out of which this initiative was born, was to 'get the ball rolling', to raise awareness of the ways to encrypt communication. now it is about time to discuss the side effects and even harmful implications of something like the 'i click a link and won't need to think about where your key is', which @mxstbr says in the intro text… and your post above just made me revisit my server's set up and yup, you can request my pubkey via http if you wanted to, that needs fixing asap :) while i was very enthusiastic with the start of this initiative, and still support the original idea to make 'getting' my key easier, i'm more than concerned about the implications should someone gain access to my server or other ways this 'easiness' could backfire. so i welcome this issue/discussion very much. :)

[mxstbr]

You raise some very good points, storing your key on your public server does assume some proficiency with system administration, which even I don't have enough of, seeing how I am struggling at the moment with getting SSL to work on pgpasc.org.

Another idea to decentralise the keys could be to distribute them randomly to everybody hosting their key on the system and then verifying the keys by comparing hashes across everybody who has your key. (i.e. how torrents work) That way you could upload your key revocation certificate, and everybody in the swarm would get rid of your old key and replace it with the key revocation cert. The next time somebody wants to check if your key is still valid, they get the key revocation cert and delete it from their storage as well. This would also allow PGP users without a web server to join the decentralisation of the keys.

While this would get rid of both the problems mentioned, it would probably require users to download software, which I think might be a hurdle. Any thoughts about this idea?

EDIT: Also, lets discuss copy changes in #2 !

[hackergrrl]

@mxstbr: sounds like a cool distributed keyserver idea. ;) Another radical place for key store could be on the/a blockchain. Though all of this may be going beyond the scope of pgp.asc, which seems geared toward zero-hassle storage of keys on one's personal web server.

What problems of keyservers is pgp.asc trying to address? There are many different keyservers out there, which can freely cross-pollinate. I liked the idea of pgp.asc because it sounded so effortless and convenient, but if adhering to this spec means very careful HTTPS setup and a rock solid secure linux configuration, the effort could create more security holes than it may have intended to plug.

[mxstbr]

After looking into this, it seems like keybase is sort–of using the blockchain, though they aren't storing the keys in there as far as I can tell. (See here: https://keybase.io/docs/server_security/merkle_root_in_bitcoin_blockchain)

[mxstbr]

Like @aral mentioned in our twitter discussion, pgp.asc might be better as a layer of discovery than a layer of verification. The HTTPS issue does make it fairly insecure, but it would be great for making e.g. an email client:

1. Write an E-Mail
2. Get the PGP key from the recipient from theirdomain.com/pgp.asc with fallbacks to silos
3. Send encrypted email

We could change the copy accordingly and leave it at that. What do you think, any comments/issues with this?

[hackergrrl]

@mxstbr: this reminds me heavily of Marc Bevand's write-up on actually using the email provider as the key provider (rather than, say, HTTP(S)).

It would change the direction of this project pretty significantly, but I really love the idea of using automated email as the request/response transport and trust system combined in such a decentralized manner.