Robert White wrote:
Claiming it as a security action is a red herring. The key files are
encrypted anyway and physical access to the database is just as
likely-or-unlikely as physical access to the keydir.
Other security products consider it very bad practice to distribute
private keys, even when encrypted. For example, encrypted private keys
in an attacker's hard disk are easily susceptible to dictionary attacks.
I think that Ethan's idea has a lot of merit. Btw, PGP allows a user to
have multiple keys associated with the same name and email. To help the
user distinguish between keys. If you list them, they look like this:
Daniel Carrera (Personal) <[EMAIL PROTECTED]>
Daniel Carrera (Foo Corp) <[EMAIL PROTECTED]>
Daniel Carrera (Bar Inc) <[EMAIL PROTECTED]>
etc
Perhaps something similar would be suitable for Monotone.
I also have an idea to help Monotone migrate from its current system to
a PGP-like system: Internally Monotone would have to use the key
fingerprint, there's no getting around that. But when the user has to
submit a key id, allow the user to provide an email or first name
instead, as long as it is unambiguous. That's what GnuPG does. I can
just say "Daniel" on the command line because I only have one key that
matches that string.
At the least we should have, on a database-instance by database-instance,
the choice of whether we want this common pollution area known a keydir.
I note that GnuPG puts keys in a common directory, and in fact, a common
file. If Monotone switched to using the key fingerprint as the file
name, that would avoid collisions. So I do not think that keydir is the
problem. I also believe that storing the private key in the DB would
have bad consequences (security and collisions).
Daniel.
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel