[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[minion-cvs] Clarify what directory signing is for and when it goes ...



Update of /home/minion/cvsroot/doc/spec
In directory moria.mit.edu:/tmp/cvs-serv2084

Modified Files:
	dir-spec.txt 
Log Message:
Clarify what directory signing is for and when it goes wrong; drop some anciently-deprecated stuff

Index: dir-spec.txt
===================================================================
RCS file: /home/minion/cvsroot/doc/spec/dir-spec.txt,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -d -r1.23 -r1.24
--- dir-spec.txt	9 Aug 2004 21:23:33 -0000	1.23
+++ dir-spec.txt	12 Aug 2004 04:53:28 -0000	1.24
@@ -114,12 +114,6 @@
    or a tab.  An EOL is an optional Space, followed by either a CR
    ('\r', ASCII 13), a NL ('\n', ASCII 10), or a CR-NL sequence.
 
-   [XXXX Is there any reason to handle non-ASCII here?  I don't want to
-    walk down the road of having a dozen competing charsets and
-    encodings. -NM]
-   [XXXX Everybody using Minion is going to support ASCII, so I think
-    it's fine to make them use it here. -RD]
-
    Here is a grammar, using C syntax for characters:
 
       Message ::= Section | Message Section
@@ -372,17 +366,6 @@
 
         'Port': A port at which IP accepts incoming MMTP connections.
 
-        'Key-Digest': The KEYID of this server, encoded in BASE64.  This
-              is the same as the SHA-1 digest of the ASN.1 encoding of
-              the identity key.  (See "minion-spec.txt" for more
-              information.)
-
-	      [XXXX This field is obsolete; it can be derived from the
-	      identity key.  We used to need it because the MMTP
-	      certificates used to be self-signed; now they are signed by
-	      the identity key.  This field will not be used in Mixminion
-	      0.0.6; it will be removed in Mixminion 0.0.7.]
-
         'Protocols': A comma-separated list of the versions of MMTP this
               server accepts.
 
@@ -726,6 +709,23 @@
         4. Signature collection (23:30 through 00:00)
         5. Publication (00:00)
 
+   In outline, voting proceeds as follows: a group of directory servers, all
+   of whom agree on the membership of the group, publish votes on which mixes
+   should be included in the directory, which mixes should be recommended,
+   and which versions of the software should be recommended.  Each member
+   collects the published votes, computes the outcome of the voting process,
+   and signs this result.  Members then collect one another's signatures,
+   and publish a multiply-signed consensus directory.
+
+   This process is not guaranteed to succeed.  If all members of the voting
+   group behave correctly, are accessible to one another on the network, and
+   are in agreement about members of the voting group, then a single
+   consensus directory signed by all members will be produced.  It is
+   possible, however, for consensus to break in several ways.  In the worst
+   case, no consensus is reached, and each directory server signs an
+   different directory.  In this case, users and directory server
+   administrators must choose how to respond; see 7.6.
+
 7.1. Research and configuration
 
    On an ongoing basis, directory servers gather information about server
@@ -775,13 +775,20 @@
 
    Once a directory server has results from all other directory servers in
    its voting group, or once the tabulation period has elapsed, each directory
-   server computes a consensus directory as follows:
+   server computes a consensus directory as follows.
+
+   [When discussions below refer to "a majority", we mean a simple majority
+   (more than one half) of the members of the voting group.  Members who
+   cast no vote in a given day (for example, because their servers are down)
+   are treated as having cast an "empty" vote -- that is, having voted
+   against every mix and against every recommended software version.]
 
       1. Validate each "vote" directory.  Verify that all formats are
          correct, and all signatures are valid.  Check that the Valid-After
          and Valid-Until times correspond to the following day; that the
          Voting-Servers list is identical to our own; that the Status is
-         "vote"; and that the Version number matches ours.
+         "vote"; and that the Version number matches ours.  If any of these
+         checks fail, do not consider the "vote" directory in step 2.
 
       2. Determine the contents of the consensus directory:
           - For each distinct mix identity in any vote directory:
@@ -835,6 +842,25 @@
    Directory servers SHOULD change their directories only at midnight
    GMT.
 
+7.6. Consensus failure
+
+   If the directory servers disagree about the consensus directory, each
+   directory server collects signatures from only whose servers who agree
+   with it about the final consensus (see 7.5 above).
+
+   If a directory server cannot find any other directory servers who agree
+   with it about the voting set, or who have signed the same consensus
+   directory, it re-signs its own first vote as its final directory.
+
+   On any day when a directory server fails to agree on a single consensus
+   directory signed by all members of its voting group, it SHOULD report to
+   its administrator that consensus has failed, and explain how.  Restoring
+   consensus (by fixing or excluding broken or misconfigured servers) is the
+   administrators' responsibility.
+
+   If clients find a consensus directory signed by insufficient trusted
+   directory servers, it SHOULD worn the user, and respond appropriately (see
+   8 below).
 
 8. Downloading directories
 
@@ -842,10 +868,12 @@
    GMT, SHOULD download a fresh directory before generating any packets.
 
    Upon downloading a directory, a client SHOULD check the signatures for all
-   of the Signed-Directory sections for which it recognizes the identity key.
-   If there are valid signatures from less than a majority of the client's
-   known servers on the directory, then the client SHOULD at least warn the
-   user.
+   of the Signed-Directory sections for which it recognizes the identity key
+   as that of a trusted directory server.  If the directory has valid
+   signatures from less than a majority of the client's trusted directory
+   servers, then the client software SHOULD at least warn the user that the
+   directory quorum could be compromised, and MAY refuse to run, or reuse an
+   older directory until consensus is reestablished.
 
 A.1. Versioning and Alphas