change the v2 dir spec to reflect how the code actually works

with respect to the directory-signature line.

this also resolves nick's issue with how to change the
directory-signature entry in votes. unless there's more to
it than that.


svn:r9182
This commit is contained in:
Roger Dingledine 2006-12-24 05:28:52 +00:00
parent 2e538d9918
commit 81aff5d529
2 changed files with 15 additions and 15 deletions

View File

@ -403,9 +403,11 @@ $Id$
The signature section contains:
"directory-signature". A signature of the rest of the document
"directory-signature" nickname-of-dirserver NL Signature
Signature is a signature of this network-status document
(the document up until the signature, including the line
"directory-signature <nick>\n") using the directory authority's
"directory-signature <nick>\n"), using the directory authority's
signing key.
We compress the network status list with zlib before transmitting it.

View File

@ -19,9 +19,11 @@ $Id: /tor/branches/eventdns/doc/dir-spec.txt 9469 2006-11-01T23:56:30.179423Z ni
This creates a partitioning problem: different clients have different
"most recent" networkstatus sources, and different versions of each
(since authorities change their statements often). Also, it is very
redundant: most of the downloaded networkstatus are probably quite
similar. Worse, the overhead grows as we add more authorities.
(since authorities change their statements often).
It also creates a scaling problem: most of the downloaded networkstatus
are probably quite similar, and the redundancy grows as we add more
authorities.
So if we have clients only download a single multiply signed consensus
network status statement, we can:
@ -65,10 +67,12 @@ $Id: /tor/branches/eventdns/doc/dir-spec.txt 9469 2006-11-01T23:56:30.179423Z ni
If an authority computes the vote wrong, its signature isn't included on
the consensus.
Clients use a consensus if it is signed by more than half the
authorities they recognize. If they can't find any such consensus,
clients either use an older version, or beg the user to adapt the list
of authorities.
Clients use a consensus if it is "trusted": signed by more than half the
authorities they recognize. If clients can't find any such consensus,
they use the most recent trusted consensus they have. If they don't
have any trusted consensus, they warn the user and refuse to operate
(and if DirServers is not the default, beg the user to adapt the list
of authorities).
2. Details.
@ -89,12 +93,6 @@ $Id: /tor/branches/eventdns/doc/dir-spec.txt 9469 2006-11-01T23:56:30.179423Z ni
authority's nickname, which MUST be unique among authorities, and
MUST match the nickname in the "directory-signature" entry.
"directory-signature" -- [XXXX this should be tagged with the nickname
or identity somehow. -NM] [The bottom of
http://belegost.mit.edu/tor/status/authority already puts the
nickname next to it. So we can just fix the spec to require
this? -RD]
Authorities SHOULD cache their most recently generated votes so they
can persist them across restarts. Authorities SHOULD NOT generate
another document until valid-until has passed.