[PATCH 3/3 v2] filter and verify keyserver responses

[Stefan Tomanek]

Dies schrieb John Clizbe (John at enigmail.net):

> Stefan Tomanek wrote:
> > This changes introduces import functions that apply a constraining
> > filter to imported keys. These filters can verify the fingerprints of
> > the keys returned before importing them into the keyring, ensuring that
> > the keys fetched from the keyserver are in fact those selected by the
> > user beforehand.
> 
> IIRC, gpg fetches keys by the most specific ID possible, for V4 keys it uses
> the fingerprint.
> 
> Are fingerprint collisions so prevalent that they must be protected against?

No, but fingerprint collisions are not necessary since gpg does not actually
check the returned data. It does not matter what gpg uses to fetch the data. I
can just send you *any* key, gpg will import it. And creating keys with
colliding short IDs has become trivial.

> > It also prevents the accidental import of secret keys through key server
> > responses.
> 
> That would certainly be more than an accident as no keyserver I know will
> store a private key.
>
> This looks like code for code's sake. It's "protecting" against nonproblems.
> More code --> more complexity --> more bugs.

Please, it doesn't matter if we encounter an "accident" or malicious behaviour:
If I issue a command like "gpg --refreshkeys", I don't expect any new keys to be
added to my keyring, and gpg should never ever touch my secret keyring. The same
goes for a specific key retrieval command by fingerprint, which should at *most*
add one new key matching that fingerprint, nothing more.

Relying on the key server playing by the rules is just a bad idea.
-- 
if(is) - Institut für Internet-Sicherheit
Westfälische Hochschule, Gelsenkirchen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: </pipermail/attachments/20130916/6b83a2f7/attachment.sig>