sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] Broken keyservers (413 Request Entity Too Large)


From: Arnold
Subject: Re: [Sks-devel] Broken keyservers (413 Request Entity Too Large)
Date: Thu, 04 Sep 2014 14:31:38 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0

On 04-09-14 08:16, Christoph Egger wrote:
> Seems uploading my gpg key (d49ae731) to pool.sks-keyservers.net fails
> for several of the hosts in rotation:

The question is: is the key too large, or should we accept keys of *every* size?

Accepting every key size does not scale well in the long term. It can also lead 
to
a nasty DOS attack: upload many huge keys to eat all the public key server
resources. We currently have no means to remove keys or specific key data.

People with a very large key can put their full key at a special place of their 
own
(they are likely to be above average active internet users). They can still 
upload
their key with exp. time and all textual UIDs. However, they should remove most 
of
the signatures and picture UIDs and instead include a 'preferred key server' 
field.

That way, the pool helps to *find* and distribute the key with a "few" 
signatures.
People receiving the key should then update that key, which will automatically 
use
the preferred key server.

This also brings us back to the question: what is the main purpose of the pool?
- Is it the ultimate key archive including all UIDs and (expired) signatures?
- Is it the place where you find all info you need to compute your trust in a 
key
(i.e. revoked and expired keys are stripped down and expired sigs and pictures 
are
removed)?
- Is it a central place to find public key data (we focus on storage of key
material, expiry and revocation data and textual UIDs)?
- ...

The problem to answer this last question is that we all operate an SKS-key 
server
for our own reasons...

Arnold



reply via email to

[Prev in Thread] Current Thread [Next in Thread]