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

[Zack Weinberg]

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?  At which point you don't have the old key handle and you can't
reconstruct the text that was signed.

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.

zw