Hello All,
After having read the recent multitude of messages related to SKS
keyservers related issue, I figured out that
a. The entire SKS keyservers design and interaction has a fundamental
design flaw named "unlimited resources assumption". I.e., it is assumed
every server, every client has unlimited resources (to store signatures;
to retrieve and process them - unlimited RAM/storage, unlimited network
speed).
b. It is only a matter of time when other certificates are under attack.
When the ones used by, say, Linux distributions to sign packages are
affected, that will cause another wave of chaos. So the only valid
option is to stop using current (the one written in OCaml) keyserver
implementation and return to stone-age practice of manually sending
them.
c. More or less valid approach would be to
- when exchanging with keyserver, only load/transmit signatures for
certificates in the user's keyring. To withstand traffic and other
resources waste, client should pass known certificates footprints first,
to only get from a keyserver the relevant signature
- implement local black/white lists feature - to able to filter out the
signatures while processing them
d. The above, or any other approach is hard to implement in foreseeable
future, even harder to make a de facto standard.
Personally, I am mostly concerned with b. at the moment. And if approach
"data came, data stay" remains in effect for keyservers, they will
merrily be flooded with junk certificates/signatures. I can see no easy
means to prevent that, without wasting resources of human users.
Am I wrong - perhaps there are brighter alternatives?
Thanks.
Sincerely,
Konstantin Boyandin
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
