Re: [Monotone-devel] Dealing with lost key

[dlakelan]

Timothy Brownawell wrote:

> Dropping anything really doesn't work with our architecture. If *anyone*
> forgets to drop it, it will come back next time that person syncs.

Ok, rather than dropping, perhaps there should be a way for a user to 
invalidate a set of certs and then create new certs to replace them. The 
idea being to tell monotone that certain certificates are known to be 
invalid (for example because a key has been discovered to be invalid or 
untrustworthy), but that we have other reasons to trust various certs 
(ie. we've validated the changes ourselves and even though the key can't 
be trusted, we want to trust the revisions based on our own certificates).

Let me give an example use case (other than the one that I have already 
encountered).

Person A has been contributing to a project that Person B is 
participating in. Person A trusts person B's key. Person B begins to 
write code that Person A does not approve of (say it has some hidden 
functionality, backdoors, etc). person A wants to invalidate person B's 
keys for all future contributions, but retain the work that was done by 
person B before. Person A also wants to communicate to other members of 
the collaboration that he does not trust person B, and that he has 
reviewed person B's code and only approves of some of the changes...

I could imagine that this sort of thing might happen every so often... 
and right now monotone doesn't seem to provide a clear mechanism for 
this kind of trust revocation and/or secondary certification.

Thanks again,
Dan