Re: [Monotone-devel] Re: Key identities...

[Stephen Leake]

William Uther <address@hidden> writes:

> Let's look at some use cases here:
>
> 1a.  A user makes a key.  They commit some stuff and push it to
> someone else.  They lose their key.  They decide to create another one
> with the same name and try to use it.
>
> 1b.  A user makes a key.  They commit some stuff and push it to
> someone else.  Dastardly Dan comes along to try and subvert the
> repository.  Dan generates a new key with the same name as the user
> and tries to use it.
>
> Note that 1a. and 1b. are indistinguishable to a third party.  

Any time someone generates a new key value, with whatever key name,
there should be a secure exchange of public keys before the new key is
given read/write permissions or trust in the remote database. That
secure exchange should distinguish 1a and 1b.

It appears the monotone philosophy is to compute read and write
permission based on key name, but compute trust based on key value?
I'm not clear on this. It is only the key name that is in
~/.monotone/write-permissions or read-permissions.

If read/write permissions were based on key value, would the problem
be detected earlier? Or go away entirely?

> In this case we have three options, 
>
> i) Assume we're case 1a and let things go ahead.

This is clearly bad.

> ii) Let things go ahead, but issue a warning of some form (e.g.
> attach a new label to the nodes to make them display uniquely) 
>
> iii) Error as soon as we can when the new key is discovered. In case
> 1a, the user then has to generate a new key with a different ID and
> continue.
>
> The end result is similar to ii), in that the string now displayed
> is similar to the old key with a label attached, but this system is
> a little more 'in your face' about the error.

In case iii), there are now three keys to deal with:

k1: original that was lost (named "address@hidden")

k2: attempted replacement (also named "address@hidden")

k3: correct replacement (named "address@hidden<2>")

In case ii, there are only k1 and k2; k1 is displayed as
"address@hidden<1>", k2 is displayed as "address@hidden<2>".

I'm not clear what should be required in ~/.monotone/write-permissions
for case ii.

In case iii, k2 is still there. Unless we are proposing to delete the
certs with k2; I don't think that is the proposal.

The core issue is how to deal with k2. I think the choices are:

1) Accept it as valid, but make sure it displays differently from k1.
   Define how read/write-permissions work for these keys.

   This is case ii).

2) Declare it "obsolete", and issue new certs with k3 for every cert
   that has k2. Define how read/write-permissions work for these keys.

   I think this is case iii), but I'm not clear.

Can monotone declare a key "obsolete"? I guess that would mean "always
error if this is the only key available for some operation". Where
would that declaration be stored?

Issuing new certs is a pain; we'd like to avoid that step if possible.
Or automate it as much as possible.

> More use cases:
>
> 2a. A user makes a key at work.  The commit some stuff and push it to
> someone else.  They then start on a new project at home.  They make a
> key for home, using the same ID.  They push it to yet another person.
> They keep working on the two projects, at home and at work, for a
> while.  After a period they try to merge these two separate
> projects.

This is the rationale for choosing globally unique key names in the
first place. But since people won't always do this, monotone should
provide for it somehow.

> Hopefully the new checks will catch those problems early.

Yes, the new checks should help.

-- 
-- Stephe