Create PKS tables in RC

[niklasfemerstrand]

Create PKS db tables in RC DB for the backend PKS to query against. Public keys received from remote PKS' should be stored in the local RC DB tbl for future lookups and the PKS should only search in remote PKS when specifically asked to do so. Grant users the option to send their public keys to the plugin backend which puts it into the PKS tbl.

The reason is because PKS', even modern ones like SKS, deliver keys over plaintext HTTP. As far as I know there is not a single PKS or even SKS serving keys over HTTPS causing the link between RC and PKS to be directly vulnerable to MITM and sniffing. RC over HTTPS is opt-in only, but at least it's better protecting HTTPS enabled RC installations all the way than leaving vulnerable links due to faulty HKP design.

Another reason is that once a key is entered into a PKS/SKS there is no way of removing it. For this reason the plugin will never support adding public keys to remote PKS/SKS but only the local RC tbl where it can be revoked by the RC admin or the user itself through future functionality.

[niklasfemerstrand]

And another reason why public keys should never be synced against key servers and why the local PK store in RC should be trusted more: http://cryptome.org/2013/07/mining-pgp-keyservers.htm

[quemquis]

I believe that the HKP protocol also supports an SSL/TLS version using HKPS, which is obviously much more secure than plaintext.

[ghost]

You certainly refer to the mit sks server which is very outdated. Nowadays, it is possible to revoke keys from sks and use hkps.

Revoke doesn't mean remove and the public key doesn't have to be removed because someone wanting to use a public key imported locally must have the possibility to check if the imported key is revoked via sks.

If the key is removed, how can a user know if the key is revoked or was just not imported in the first time.

If you really want to reinvent the wheel and make your own hybrid RC-sks, please let the possibility to use a remote sks server with all its features.

Do not forget that the keys used in roundcube can be used in several other applications, as for example Thunderbird with enigmail, so the PKI has to be easily accessible by all these apps.

That plugin is very interresting but I completely disagree with the option you want to implement. Security is also the faculty to use standard, widely-tested, well-proven technologies and I am sorry but I don't think you can guarantee the same quality than hundreds of developers working on sks.

Thanks to take the time to read me.

[quemquis]

I understand your misgivings regarding SKS, but a properly implemented sks server should be fairly secure (hkps). In my case, I run my own private SKS on the same host as RC so it's always a local connection anyway. Also, my SKS doesn't sync upstream since I disabled that option. That gives me more control over the keys in my private, closed network, which your plugin can query as needed.

By the way, a word of warning to those imlementing their own SKS. The default option in SKS is to automatically sync upstream, which is a pain if you're not paying attention and have no desire for your public keys to be out there on the interwebs.

[niklasfemerstrand]

@Lengronne:

"If you really want to reinvent the wheel and make your own hybrid RC-sks, please let the possibility to use a remote sks server with all its features."

Yeah, I do. Mainly to get a local storage into Roundcube so that the RC admin can delete keys that can no longer be used and to not have to rely on centralized key stores. There actually already is a key server, except for local storage obviously, built into the plugin, what are you missing? I can build it. :-)

"If the key is removed, how can a user know if the key is revoked or was just not imported in the first time."

If the key is not removed, how can the sender know which one of a recipient's multiple keys to encrypt with?

"Security is also the faculty to use standard, widely-tested, well-proven technologies and I am sorry but I don't think you can guarantee the same quality than hundreds of developers working on sks."

Agree, but HKP is not a standard - it actually never left draft stage: http://tools.ietf.org/html/draft-shaw-openpgp-hkp-00

"Do not forget that the keys used in roundcube can be used in several other applications, as for example Thunderbird with enigmail, so the PKI has to be easily accessible by all these apps."

Private keys will have to be manually transferred between these applications no matter what, why not the public keys as well? It's not easy transferring keys from a web application to a local binary automatically without losing in security.

"I am sorry but I don't think you can guarantee the same quality than hundreds of developers working on sks."

This quality that you're talking about, where in HKP/SKS is it? Is it quality that anybody can submit any public key with any ident and it gets stored without any form of verification, even though each key is tied to an e-mail address by design? Is it quality that keys can not be removed unless the user still has the private key in his posession? The most popular reason why a user would remove a public key from such a key server would be that they lost the private key or its passphrase making revokation impossible and thus leaving zombie keys in store.

Is this quality? http://cryptome.org/2013/07/assange-pk-19days.htm

If I've missed something please point it out. These are my issues but if there are public key servers that have addressed and solved these issues of course I have no problem writing support for them.

[niklasfemerstrand]

@quemquis:

"In my case, I run my own private SKS on the same host as RC so it's always a local connection anyway. Also, my SKS doesn't sync upstream since I disabled that option. That gives me more control over the keys in my private, closed network, which your plugin can query as needed.

By the way, a word of warning to those imlementing their own SKS. The default option in SKS is to automatically sync upstream, which is a pain if you're not paying attention and have no desire for your public keys to be out there on the interwebs."

Excellent! This is the entire reason of why I'm building a key server into the plugin. I don't like centralization. Key lookups against SKS/PKS is already available via hkp_search() in rc_openpgpjs.php. On hkp_add() there is a comment saying "Don't sync upstream, it hurts decentralization".

My entire idea is to force decentralization by only querying remote, in your case a local, key server when the queried key is missing in the local storage. It's quite a ghetto patch but it makes it harder creating zombie keys, as you describe in the last paragraph. This has already been thought of, :-)

[ghost]

hkp is the standard de facto. I agree it is not complete.

The problem of binding an information system to a human being is not a sks fail, all systems have that problem. How can you assure a perfect binding, the password of roundcube can be stolen. Do you have a system to take the DNA of an individual ^^ ?

It is more secure to rely on an automated system to transfer public keys than to do it manually because the risk of key corruption is less.

But thanks to say that you can build again to increase the implementation of sks.

sks is not the perfect system, I agree. There was once a system based on ldap but the project was given up. But it is the better currently present. As for the multiple keys for one user, it can be shown as a key for each device of this user.

There is no meaning to force a correlation 1 user = 1 key. It can be 1 user = n keys or 0 user = n keys if you want to attach a key to a file or a firm.

[ghost]

But for example, to avoid zombie keys, you can force a key signature with multiple keys, one being the admin one.

[lazlolazlolazlo]

I think it might be a good idea to write a threat model for this local key server and maybe in generally for rc_openpgpjs.

[ghost]

I found something interesting. Maybe, you should see.

https://github.com/jprlauzier/pgpserver http://pgpserver.com/

[niklasfemerstrand]

https://gitorious.org/openhkp-js/openhkp-js/source/deca0bd37f6dc18fbd16362f21047cf8c125b147: