SKS and GnuPG related issues and possible workarounds

Konstantin Boyandin lists at boyandin.info
Wed Jul 3 05:28:33 CEST 2019


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



More information about the Gnupg-users mailing list