monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL


From: Brian May
Subject: Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL
Date: Tue, 21 Oct 2008 14:24:24 +1100
User-agent: Thunderbird 2.0.0.17 (X11/20080925)

Daniel Carrera wrote:
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) <address@hidden>
Daniel Carrera (Foo Corp) <address@hidden>
Daniel Carrera (Bar Inc) <address@hidden>
etc


Perhaps something similar would be suitable for Monotone.

You need a secure means of assigning a name for each key. GnuPG does this by allowing keys to be signed by other users, ie. creating a "web of trust"[1]. I am not convinced reproducing this web of trust for monotone is a good idea, it would be better if we could somehow reuse the web of trust already with GnuPG.

Was there a good reason why monotone didn't use GnuPG for signatures? I have a feeling it was related to speed or something.

In that case, why not create a file with the following information:

* hash of key
* date?
* list of email address for key
* etc

GnuPG sign this to form a certificate, store it in ~/.monotone/certificates/<hash>.xxx

When monotone needs to look up the name of the user associated with key <hash> it can lookup ~/.monotone/certificates/<hash>.xxx, verify the hash matches, verify the signature is good (using GnuPG), and then obtain the email address from the file.

For a variation on the above theme, allow changing /GnuPG/x509 using OpenSSL/ - there are similar web of trust schemes for x509 now, eg. www.cacert.org.

Note:

[1] somebody else used the term "web of trust" recently here to mean something else entirely, I use the term to mean GnuPG keys that are signed by different people, so if A trusts Bs key and B trusts C key, then A can trust C. Either that or there was a misunderstanding.

Brian May





reply via email to

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