hello all,
From: Hironobu SUZUKI <hironobu(_at_)h2np(_dot_)net>
Subject: Re: rfc2440bis-02 comments
Date: Wed, 27 Dec 2000 13:33:38 +0900
2 years ago, I got a complain e-mail about adding public key by a
third party. Then I thought multi-phase commit for keyserver. But my
idea looks crypto-over-kill for our public keyserver.
[ detailed description of pk-based challenge-response scheme snipped ]
This solution is not simple and powerful CPU is required for
keyserver. But I'm not sure that it is too much cost for keyserver.
Please note that this is only idea and I don't recommend it.
to add more hypothetical information to the situation...
if keyservers are going to do authentication-like things (a big "if"),
why not do the following:
-before adding a key from the queue to a database, use an email confirmation
system to solicit confirming email (don't need to use pk-based
challenge-response for this) -- just use what many mailing list
systems use. if confirmation is obtained, add the key to the database.
-in order to remove a key from the database, use a challenge-response
system like Hironobu described.
-keys expire from servers by default. perhaps 6 months or 1 year.
points to observe:
-if deletions are relatively scarce events, you don't need much cpu
power. keyservers can even decide to only service delete requests
periodically in bulk.
-in the case that the confirmation by email process is "spoofed" and
a third party adds someone's key, the holder of the secret key can remove
the key using the above method. i'm assuming the spoofing shouldn't
be something that should continue to happen to a particular individual --
if it does, imo, that person has other problems that need to deal with
first.
-an "expire-from-server" time field (only allowed in the hashed area)
could be defined in rfc 2440, support for this in keyservers and
openpgp client implementations seems like one way to accomplish the
expiration idea.
-unused keys will be removed from servers over time. less garbage is
collected and people who lose their secret keys can relax after a while.
new users can be encouraged to choose short "expire-from-server" times.
i think it's important to be able to update one's "expire-from-server"
time -- i don't understand how key information on keyservers gets
updated (which key information takes priority? always what gets submitted
later in time? if so, may be something like a "timestamp" field is
necessary in the hashed area so that a keyserver can decide which key info
is more recent).
-it's not required that keys have email address info associated w/ them.
it's not clear to me whether one would bother w/ confirmation for these.
thoughts?