Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0

[Timothy Brownawell]

On Thu, 2009-08-27 at 16:44 -0700, Zack Weinberg wrote:
> On Tue, Aug 25, 2009 at 9:38 PM, Timothy Brownawell<address@hidden> wrote:
> >> It sounds like the keys-by-hash change introduces a weaker sort of
> >> cert flag day, where old signatures can no longer be unambiguously
> >> verified (do I understand correctly?) However, there's a
> >> straightforward way to keep old history meaningful (see below), and it
> >> doesn't sound like it will be hard to keep speaking the old protocol
> >> (modulo negotiation issues) so we should.
> >
> > The old-format certs become ambiguous about which key they were signed
> > with. They can be disambiguated by trying to verify the signature
> > against each matching key (typically there will only be one) and seeing
> > which one works. But you might not be easily able to obtain the correct
> > key, if the (old-format) server knows a different key with the same
> > name.
> >
> > Once the certs are taken off the wire they'll be matched with the
> > correct key (or I guess dropped with a warning if we can't find that
> > key) before being stored in the db, so any ambiguity will be confined to
> > netsync time.
> 
> I'm confused.  The old signatures are over text including the old key
> id.  How do you verify the signature on an old cert if you don't have
> a definitive way of identifying the old key id?  I mean, the *point*
> of this change is that keys' user visible handles can now be changed,
> ya? 

The point is that (1) public_keys.key_name is no longer a primary key,
and (2) revision_certs.key now instead points to public_keys.key_hash,
because that is cryptographically unique rather than unique by fiat.

This means that someone who loses their private key and generates a new
keypair with the same name, doesn't cause headaches for everyone else.

People are still not allowed to change the name attached to a given set
of RSA numbers, because that association is not versioned and there's
therefore no way to communicate a change (hmm, actually, key_hash =
fn(key_name, public_numbers), so if someone edited their key name
manually it would look look like a distinct key that happens to produce
identical signatures).

>  At which point you don't have the old key handle and you can't
> reconstruct the text that was signed.

void
cert::signable_text(string & out) const
{
  base64<cert_value> val_encoded(encode_base64(this->value));
  string ident_encoded(encode_hexenc(this->ident.inner()(),
                                     this->ident.inner().made_from));

  out.clear();
  out.reserve(4 + this->name().size() + ident_encoded.size()
              + val_encoded().size());

  out += '[';
  out.append(this->name());
  out += '@';
  out.append(ident_encoded);
  out += ':';
  append_without_ws(out, val_encoded());
  out += ']';

  L(FL("cert: signable text %s") % out);
}

What is signed is fn(cert_name, revision_id, cert_value), which does not
include the key name.

The cert *hash*, which is only used by netsync, includes these plus the
key (key_name previously, now key_hash) and the signature (ie,
"everything in the revision_certs table, except for itself").

...oh, cool. Including the signature means that even without explicitly
including the key_hash, the same name/value pair signed by different
keys with the same name will still have different hashes. So the cert
hashes can actually stay the same, they just lose the property of being
"everything in the revision_certs table, except for itself".

> This is what I was trying to solve with the voucher certs.
> 
> > I guess the trust hooks would see this as if the voucher key had signed
> > the original certs?
> 
> I'd prefer it if the trust hooks saw it as if the original key had
> signed the original certs.

So then someone who broke the old hash can fake an old cert and use any
random key to put a voucher cert over it, and your hooks will trust it
as if it was signed by, say, your project leader.

It would have to either be that the voucher key appears to have signed
the certs, or that the trust hooks are taught to understand "he says
that she says that ..." which is a bit more complicated for everyone.

-- 
Timothy

Free public monotone hosting: http://mtn-host.prjek.net