103-multilevel-keys and 101-dir-voting
Nick Mathewson
nickm at freehaven.net
Mon Apr 30 17:16:13 UTC 2007
On Mon, Apr 30, 2007 at 02:22:39AM -0400, Roger Dingledine wrote:
Hi, Roger, and thanks for your comments! I've cleaned up 103 a bit in
response.
> On Sat, Apr 21, 2007 at 01:48:58PM -0400, nickm at seul.org 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.
It is the whole key. I was thinking we should do what we do now with
identity keys: the client ships with a hash of all the authorities'
identity keys, but not the actual keys themselves. Thus, the key
would need to be included so the client can tell what it is, but the
client would recognize bad keys.
(We ship clients with only the hashes for router identity keys because
our configuration system deals with one-line configuration options far
better than with inline keys. We used to ship with an authority keys
file, but I seem to recall this as having been annoying.)
> > + "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?
The point of this entry is to make sure that we have the current
signing key in the key certificate. When we fetch a bunch of key
certificates, we want to be sure that we don't replace a new key with
an old key. Having a published time makes this trivial.
I agree that this isn't quite needed for vote processing; it matters
only for the key certificate.
> 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?
Right. These fields are needed for key certificates. I put them into
the vote documents because it is vital to have an up-to-date
certificate to process a vote, and because space-efficiency for votes
doesn't matter much.
For expositional reasons, when we merge this into dir-spec-v3.txt, we
should describe key certificates, and _then_ say that they're included
verbatim as part of votes.
>
> > + "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. :)
Okay, I'll clean this up, and do the exposition I want.
>
> > + The "fingerprint" field is generated based on the identity key, not
> > + the signing key.
>
> Doesn't this make it redundant with dir-identity-key?
The "fingerprint" field appears in consensus documents.
dir-identity-key doesn't.
Also, note that we have both fingerprint and identity key in router
descriptors. The fingerprint is helpful because people often want to
identity a router by fingerprint, but calculating the hash of a key by
hand is not trivial.
> Also, is it useful somewhere to bind the directory identity key to the
> router identity key?
I don't think so. Can you think of an application for this?
>
> > + 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?
Yes, sure.
> In fact, should we just get rid of dir-source?
I don't think so. It's useful when tracking which consensus directory
we're actually looking at, and where the authorities are today.
>
> > + 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?
This:
Processing votes:
When receiving a vote, authorities check to see if the key
certificate for the voter is different from the one they have.
If the key certificate _is_ different, and its dir-key-published
is more recent than the most recently known one, and it is
well-formed and correctly signed with the correct identity key,
then authorities remember it as the new canonical key
certificate for that voter.
A key certificate is invalid if any of the following hold:
* The version is unrecognized
* The fingerprint does not match the identity key.
* The identity key or the signing key is ill-formed.
* The published date is very far in the past or future.
* The signature is not a valid signature of the key certificate
generated with the identity key.
When processing the signatures on consensus, clients and caches act
as follows:
1. Only consider the directory-signature entries whose identity
key hashes match trusted authorities.
2. If any such entries have signing key hashes that match
unknown signing keys, download a new keys document.
3. For every entry with a known (identity key,signing key) pair,
check the signature on the document.
4. If the document has been signed by more than half of the
authorities the client recognizes, treat the consensus as
correctly signed.
If not, but the number entries with known identity keys but
unknown signing keys might be enough to make the consensus
correctly signed, do not use the consensus, but do not
discard it until we have a new keys document.
> 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.
Okay. I don't think we have a status for this. Should we loosen the
status of "Accepted", or add a new "Trying to code" status?
yrs,
--
Nick Mathewson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20070430/1024b1ca/attachment.pgp>
More information about the tor-dev
mailing list