Re: 103-multilevel-keys and 101-dir-voting

[Roger Dingledine <arma@xxxxxxx>]

On Sat, Apr 21, 2007 at 01:48:58PM -0400, nickm@xxxxxxxx wrote:
> Modified: tor/trunk/doc/spec/proposals/103-multilevel-keys.txt
> ===================================================================
> --- tor/trunk/doc/spec/proposals/103-multilevel-keys.txt	2007-04-21 17:48:45 UTC (rev 9999)
> +++ tor/trunk/doc/spec/proposals/103-multilevel-keys.txt	2007-04-21 17:48:50 UTC (rev 10000)
> +Extensions to Proposal 101.
> +
> +  Add the following elements to vote documents:
> +
> +     "dir-identity-key": The long-term identity key for this authority.

Is this a base16 hash, or the whole key? Seems to me that either the
client knows the identity key already from the keys file we ship, in
which case a hash is sufficient, or he doesn't, in which case he doesn't
care what it is because he won't trust it anyway.

> +     "dir-key-published": The time when this directory's signing key was last
> +         changed.

I guess the point of this entry is that if we don't have the appropriate
signing key, yet it was published before the keys.z we have, we won't try
to fetch a new keys file? Another use would be to be able to recognize
when a given signing key is older than one we already have, in which
case we can...we can what?

I'm trying to figure out if this is needed here. Is it just for the
sake of completeness, and since it's just a vote we don't worry too much
about efficiency?

> +     "dir-key-certification": A signature of the fields "fingerprint",
> +         "dir-key-published", "dir-signing-key", and "dir-identity-key",
> +         concatenated, in that order.  The signed material extends from the
> +         beginning of "fingerprint" through the newline after
> +         "dir-key-certification".  The identity key is used to generate this
> +         signature.

> +      The elements "fingerprint", "dir-key-published", "dir-signing-key",
> +      "dir-identity-key", and "dir-key-certification" together constitute a
> +      "key certificate".  These are generated offline when starting a v2.1
> +      authority.
> +
> +      The elements "dir-signing-key", "dir-key-published", and
> +      "dir-identity-key", "dir-key-certification" and MUST NOT appear in
> +      consensus documents.

The two 'ands' here, plus the missing 'and', make me nervous that this
wasn't the list you actually intended to produce. :)

> +      The "fingerprint" field is generated based on the identity key, not
> +      the signing key.

Doesn't this make it redundant with dir-identity-key?

Also, is it useful somewhere to bind the directory identity key to the
router identity key?

> +  Consensus network statues change as follows:
> +
> +      Remove dir-signing-key.
> +
> +      Change "directory-signature" to take a fingerprint of the authority's
> +      identity key rather than the authority's nickname.

This will affect how we define dir-source too, since it wants the
dir-source to match the nickname in the directory-signature. Shall we
just list a hash of the identity key as the dir-source too? In fact,
should we just get rid of dir-source?

> +  Add a new document type:
> +
> +      A "keys" document contains all currently known key certification
> +      certificates.  All authorities serve it at
> +
> +          http://<hostname>/tor/status/keys.z
> +
> +      Caches and clients download the keys document whenever they receive a
> +      consensus vote that uses a key they do not recognize.  Caches download
> +      from authorities; clients download from caches.
> +
> +  Verification:
> +
> +      [XXXX write me]

What's in the verification section?

In general, I think we're moving in the right direction here, and it's
a fine time to start coding if you'd like to (which from talking to you
it sounds like you do). Let us know if you run into any other troubles
that are non-obvious.

Thanks!
--Roger