On Sun, 27 Jun 2010, David Shaw wrote:
However, you raise another question: How does a keyserver know who is
uploading the key?
At the moment, it doesn't. That would need to be addressed if you
want keyservers to be able to reject a no-ks-modify key. One way to
do it is to only accept key updates that are signed by the key itself.
But, of course, to do that, the keyserver needs to be able to verify a
signature...
That's one way. Another is to do it the keyserver.pgp.com way, and
email the primary uid a cookie. No crypto required. RFC2440 doesn't
at all require that the authenticity be verified cryptographically.
Correct?
Correct, but then, RFC-2440 or 4880 doesn't say much about keyservers at
all. It's mainly a message format document. Semantics of keyservers
are not specified beyond one or two minor things like the no-modify flag
and the "preferred keyserver" field.
The difficulty with mailing the primary user ID a cookie is that it
pretty much means your server can't synchronize with any other server.
Keyserver A updating keyserver B for key "foo" would in essence be someone
other than the owner, even if they're in the same "pool", as keyservers
can have multiple names. Assumably if I have enough sense to set my
preferred keyserver url (either to a keyserver or to a private url), I
know which keyservers are islands and which are pools.
I presently consider synchronization broken. If there were only one
network of keyservers out there, and I didn't have to search multiple
places when trying to sign or request a key, I might think otherwise, but
this is not the case. See my alternate request about being able to use
multiple urls in auto-key-locate, which I don't believe currently works.
I'm also not aware of how servers synchronize, but if it's a different
protocol than the standard single-key-request protocol, then there's an
easy metric to say "don't hand out keys with this flag via this protocol".
Perhaps if I get deeply into this, I could define keyservers which were
aware of which other ones did verification.
Since your server would have an entrance restriction, and the other
servers won't, that means that your server would have to either reject
keys from other servers (i.e. not syncing) or apply the same restriction
(email user IDs from keys that weren't uploaded directly to your
server). keyserver.pgp.com solves this by simply not syncing to anyone
else. That makes it a completely opt-in server.
I wasn't against this plan. This was (as mentioned) for work on a private
keyserver whose changes would be merged upstream. Consider it an initial
step toward the whole.
However, I think you're still missing my question: is it necessary for
the keyserver to be crypto-aware if I just want a keyserver to reject
those keys outright? Is there crypto involved in reading that flag, or
is it just a simple parse? From reading RFC2440 it seems the latter,
but I certainly respect you've been doing this longer than I :)
There is crypto involved in showing that the flag is real - that the
keyholder set the flag, and not someone just setting the flag for
malicious reasons.
For example, take the case of a key with the no-modify flag set (i.e.
the keyholder doesn't want the key on a keyserver). The attacker takes
this key, and removes the flag. He then sends the key to a keyserver
without crypto. The keyserver sees the key has no flag, so accepts it.
This allows an attacker to violate the keyholder's requirements. If the
keyserver had crypto, it would know that the key had been tampered with
and the flag removed.
At present, no keyservers respect this flag, with or without crypto. So
that's not much of a leap, anyway. This "attack vector" exists now. I'm
sure more than a few people have been annoyed that their keys wound up on
a server, as I had read in a previous (and very long) thread.
Without at all getting into the "flag" argument, do you feel keyservers
should be verifying selfsigs before publication, or do you think they
should remain "dumb"? Both imply some problems, but your statement as to
keyservers not doing crypto didn't seem to imply whether you're for or
against it, and I'm curious.
-Dan
--
--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---------------------------
_______________________________________________
Gnupg-users mailing list
[email protected]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
