Deleting or Higing of Keys

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Deleting or Higing of Keys

Olaf Gellert
Hi all,

after some thinking (and some thoughts about privacy
and other issues of responsiblities of keyserver admins),
I want to rise the discussion again about removing keys
from the keyservers.

- Right now keyservers do publish any keys that get
  submitted to them. They distribute the keys among
  other keyservers.

- Keys may be published without the knowledge of the
  owner. They usually contain personal data (at least
  the email address of the owner).

- Keys may even contain worse. Keyservers do not really
  check the contents of the keys, so anyone may sent
  additional packets (not even constrained to his own
  key). I can imagine a little perl script adding some
  naughty images to every key on the keyserver... ;-)

- So I guess, what we do need is a means to remove keys
  from the keyservers. It may be sufficient to only hide
  them (which could prove to be much easier to implement
  with regard to the syncing mechanisms).

- How about other keyservers than SKS or HKP? There
  were some efforts spent on keyservers doing signature
  checks and other crypto stuff. Could prove to be
  helpful in some of these issues...

Some thoughts about this? How difficult would it be to
implement such a feature in SKS or other keyservers?
Ayn takers? (unfortunately I do not have a clue about
OCAML)...

Cheers, Olaf

--
Dipl.Inform. Olaf Gellert                  PRESECURE (R)
Senior Researcher,                       Consulting GmbH
Phone: (+49) 0700 / PRESECURE           [hidden email]

                        A daily view on Internet Attacks
                        https://www.ecsirt.net/sensornet



_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Deleting or Higing of Keys

Seth Hardy
> - Keys may even contain worse. Keyservers do not really
>   check the contents of the keys, so anyone may sent
>   additional packets (not even constrained to his own
>   key). I can imagine a little perl script adding some
>   naughty images to every key on the keyserver... ;-)

*cough*

i haven't written a script to add naughty images (but thanks for the
idea! ;), but i do have scripts for doing other sorts of similar
nastiness. actually mentioned a number of these obnoxious "attacks" on
the keyserver network in a talk i gave at the ccc congress this past
year.

> - So I guess, what we do need is a means to remove keys
>   from the keyservers. It may be sufficient to only hide
>   them (which could prove to be much easier to implement
>   with regard to the syncing mechanisms).

the pgp global directory is doing this already. their take on the
problem is just to verify via email address -- so this is only really
useful if you're using the key for email, and it breaks if you lose
access to your email account. basically if you want your key removed,
they verify you by email. they also do periodic pings of all people in
the keyserver to see if they're still alive, and prune people who don't
respond (in 6 month intervals).

this opens up other problems... what if you lose access to the email
account? what if someone forges or intercepts email? etc. but the
options you have if you've lost your secret key are somewhat limited, so
it may be an acceptable tradeoff for some/most people.

- seth

--
seth hardy: [hidden email] * 617.650.xxxx * www.aculei.net/~shardy
(gpg - 0x5E345628): BF63 A0A7 3BCA 1D7D EDE1 63BF 46FB 95D9 5E34 5628
            "Never offend people with style when you
               can offend them with substance." -- Sam Brown

_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Deleting or Higing of Keys

Yaron Minsky
This is the not-so-well-kept secret of the public keyserver system.  SKS was designed as a showcase for a cool replication algorithm, and as such it didn't make any attempt to improve on the security model of PKS.  Rethinking the basic security model is undoubtedly a good idea, since the current one sucks so badly.   But it does require some real thinking to choose a model that makes sense for the loosely coordinated federation that is the public keyserver system.  And any such change will probably introduce incompatibilities between old and new servers.

y

On 6/9/05, Seth Hardy <[hidden email]> wrote:
> - Keys may even contain worse. Keyservers do not really
>   check the contents of the keys, so anyone may sent
>   additional packets (not even constrained to his own
>   key). I can imagine a little perl script adding some
>   naughty images to every key on the keyserver... ;-)

*cough*

i haven't written a script to add naughty images (but thanks for the
idea! ;), but i do have scripts for doing other sorts of similar
nastiness. actually mentioned a number of these obnoxious "attacks" on
the keyserver network in a talk i gave at the ccc congress this past
year.

> - So I guess, what we do need is a means to remove keys
>   from the keyservers. It may be sufficient to only hide
>   them (which could prove to be much easier to implement
>   with regard to the syncing mechanisms).

the pgp global directory is doing this already. their take on the
problem is just to verify via email address -- so this is only really
useful if you're using the key for email, and it breaks if you lose
access to your email account. basically if you want your key removed,
they verify you by email. they also do periodic pings of all people in
the keyserver to see if they're still alive, and prune people who don't
respond (in 6 month intervals).

this opens up other problems... what if you lose access to the email
account? what if someone forges or intercepts email? etc. but the
options you have if you've lost your secret key are somewhat limited, so
it may be an acceptable tradeoff for some/most people.

- seth

--
seth hardy: [hidden email] * 617.650.xxxx * www.aculei.net/~shardy
(gpg - 0x5E345628): BF63 A0A7 3BCA 1D7D EDE1 63BF 46FB 95D9 5E34 5628
            "Never offend people with style when you
               can offend them with substance." -- Sam Brown


_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel





_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel