$Id: dir-spec.txt,v 1.33 2005/11/01 18:19:52 nickm Exp $ MIX3:3 Type III (Mixminion) Mix Directory Specification George Danezis Roger Dingledine Nick Mathewson (who else?) Status of this Document This draft document ("dir-spec.txt") describes a proposed specification for Type III Remailers. It is not a final version. It has not yet been submitted to any standards body. Abstract This document describes the protocols and message formats used by Type III mix servers and Type III directories compatible with the Mixminion reference implementation, and with the forthcoming Mixmaster 4. See "minion-spec.txt" for information about the Type III protocol itself. Table of Contents Status of this Document X Abstract Table of Contents 1. Introduction 1.1. Terminology 2. Type-III information exchange format 2.1. Message format 2.2. Processing unrecognized information 2.3. Processing corrupt information 2.4. Representing data 2.5. Calculating digests and signatures 3. Server descriptor format 3.1. Server identity 3.2. Descriptor liveness 4. Directory formats 4.1. Multiply-signed format (0.0.8 and later.) 4.1.1. Migration note 4.2. Singly-signed format (pre-0.0.8) 5. Directory protocols 5.1. Retrieving a directory 5.2. Publishing a server descriptor 6. Generating server descriptors 7. Generating directories 8. Downloading directories A.1. Appendix: Versioning and alphas A.2. Appendix: Suggested path selection algorithm 1. Introduction For a Mix network to provide anonymity to its users, it is vital that those users provide cover traffic to one another by behaving as similarly as possible when choosing paths and servers for their messages. Because of this, it is vital that users have a means to learn about usable Mixes -- and that this means yield identical results for all users. Furthermore, because the Type-III Mix protocol relies on regular key rotation in order to limit the size of replay caches and mitigate the effect of key compromise, it is necessary for servers to be able to propagate information about their state to users. This document specifies the message formats and protocols used by the type-III remailer network to exchange information about servers. 1.1. Terminology * Server Descriptor - A human-readable text message describing a set of keys and capabilities for a single Mix. * Directory - A human readable text message describing a list of Mixes and their keys. * Identity Key - A long-term signing RSA key used for authenticating server descriptors and directories. * Nickname - A human-readable unique identifier for a Mix. This document uses the terms "MUST", "SHOULD", "MAY", "MUST NOT", "SHOULD NOT", and "MAY NOT" as defined in RFC 2119. 2. Type-III Information Exchange format To simplify the work required to write a parser for message formats, we base server descriptors on the following extensible meta-format. 2.1. Mix Information Exchange format Informally, a Mix Information Message is a sequence of newline-separated key-value pairs, with a colon between keys and values. These pairs are divided into sections; each section begins with a square-bracketed section identifier. Blank lines are not allowed. Formally, a Mix Information Message is a sequence of ASCII characters, consisting of one or more Sections. Each Section contains a Header, and one or more Entries. Each Header consists of a left square-bracket ('[', ASCII 91), an Identifier, a right square-bracket (']', ASCII 93), and an EOL. Each Entry consists of an Identifier, a colon (':', ASCII 58), a Space, a Value, and an EOL. An Identifier is a sequence of one or more printable nonspace characters other than colon and brackets (ASCII 33-57, 59-90, 92, 94-126 inclusive). A Space is a sequence of one or more tab ('\t', ASCII 9) or space (' ', ASCII 32) characters. A Value is a sequence of zero or more printing ASCII characters, excluding NL and CR (ASCII 9, 32-126 inclusive), and not beginning with a space 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 Everybody using Minion is going to support ASCII, so I think it's fine to make them use it here. -RD] [XXXX Contact Information and comments desgined to be read by humans may want to be encoded in UTF-8. -PP] Here is a grammar, using C syntax for characters: Message ::= Section | Message Section Section ::= Header | Section Entry Header ::= '[' Identifier ']' OptSpace EOL Entry ::= Identifier ':' Space OptValue EOL Identifier ::= IdentifierChar | Identifier IdentifierChar IdentifierChar ::= [Any character from ASCII 33 through ASCII 126 inclusive, excluding ASCII 58, ASCII 91, ASCII 93.] OptValue ::= Value OptSpace | Value ::= NonSpaceValue | Value Space NonSpaceValue NonSpaceValue ::= NonSpaceValueChar | NonSpaceValue NonSpaceValueChar NonSpaceValueChar ::= [Any character from ASCII 33 through ASCII 126 inclusive.] Space ::= SpaceChar | Space SpaceChar SpaceChar ::= ' ' | '\t' OptSpace ::= Space | EOL ::= '\n' | '\r' | '\r' '\n' An example follows (indented by a uniform number of spaces): [Section1] Key1: Value1 [Empty_Section] [Section-Three] Key-two: the second value is this value Key3: (Note: the space after "Key3:" above is not optional.) 2.2. Processing unrecognized information To enable backward-compatible extensions of the Exchange format, all processors of Mix Information Exchange Messages MUST behave as follows when encountering unrecognized headers or entries. When processing a section with an unrecognized identifier, the processor must ignore the section completely. When processing a section with a recognized identifier, the processor must check whether it recognizes the version number of that section (usually encoded in an entry with the identifier 'Version'). If it does not recognize the version number, the processor must ignore the section completely. When encountering an entry with an unrecognized identifier, the processor must ignore the entry. 2.3. Processing corrupt information In case an implementation encouters information that is not correctly signed or does not conform to the syntax specified in this document the following behaviour is RECOMMENDED. If a mandatory section of the directory is missing, or any field in any of the mandatory directory sections is missing or does not conform to the specified syntax, then entire directory SHOULD be rejected. If a server descriptor's digest or signature does not verify then the entire directory SHOULD be rejected, as this is a sign of a malfunctioning directory server. If a mandatory section of a server descriptor, or a mandatory field in a mandatory section of a server descriptor is missing, then this server descriptor SHOULD be ignored. If the value of any field (mandatory or not) of a mandatory section in a server descriptor does not conform to the specified syntax, then this server descriptor SHOULD be ignored. If a mandatory field in an optional section is missing, then this section SHOULD be ignored. If the value of any field (mandatory or not) of an optional section does not conform to the specified syntax, then this section SHOULD be ignored. 2.4. Representing data All formats use the following conventions to convert encoded values to and from their underlying semantic meaning: - Trailing whitespace is always ignored; sequences of whitespace are collapsed to a single space. - All numeric quantities are represented in decimal. - All dates are represented in YYYY-MM-DD format. - All times are represented in YYYY-MM-DD HH:MM:SS or YYYY-MM-DD HH:MM:SS.mmmm format, relative to UTC. [Compatibility note: Mixminion through 0.0.4 generates and accepts only US-style YYYY/MM/DD dates. To transition to ISO-style YYYY-MM-DD dates, version 0.0.5 will accept both styles and generate only US style. Version 0.0.6 will accept both styles and generate only ISO-style. Version 0.0.7 will accept and generate only ISO style.] - All binary data is base-64 encoded (with no whitespace, as recommended by RFC 3548). - All boolean values are encoded as 'yes' or 'no'. - All RSA public keys are first encoded to binary with ASN.1, then encoded in base-64 (again with no whitespace). - 'Address Patterns' are encoded according to the following grammar: AddressPattern ::= Address OptPortSpec Address ::= '*' | IP OptMask OptMask ::= '/' IP | IP ::= OptPortSpec ::= | Port | Port '-' Port An omitted mask defaults to 255.255.255.255. '*' is a synonym for 0.0.0.0/0.0.0.0. An omitted PortSpec defaults to 48099 for 'allow' entries and 0-65535 on 'deny' entries. [XXXX please consider using cidr notation instead. e.g. 192.0.2.0/24 -PP] [XXXX Tentatively agreed, but it is very possible that none of the Address Pattern uses will ever get implemented, so I'll hold off on revising this for a bit. -NM] - Unless specified otherwise, all 'sorted' lists are sorted lexically by their ASCII encodings, in ascending order. 2.5. Calculating digests and signatures Several places in this specification require Messages to be self-signed with a given identity key. The digest of a message is computed with the following steps: - First, any trailing whitespace on any line is removed, and every EOL is converted to a single NL character. - Second, the message is converted to a "stub" format: the values of any _unsigned entries_ in the message are replaced with the empty string, and trailing space is removed from their lines. (Their entry lines now contain an identifier, a colon, and a single NL character.) Any _unsigned sections_ in the message are removed entirely. - Third, a SHA-1 digest is computed over the resulting stub message. When signing a message, the signature is computed by taking the RSA signature of the digest with OAEP/PKCS1 padding and encoding, as described in "minion-spec.txt". RSA signatures are encoded in base-64. 3. Server Descriptor format This section describes the format of server descriptors, as uploaded to and downloaded from directory servers. A server descriptor is a promise, by a mix's administrators, to provide a given set of services, keys, and exit policies over a set period of time. A server descriptor consists of one or more sections. The first section must be a 'Server' section. This section MUST include each of the following entries in any order, exactly once. 'Descriptor-Version': the string '1.0' 'Nickname': A human-readable identifier for this server. It MUST NOT be more than 24 characters. It MUST contain only the characters [A-Za-z0-9] and '-'. It MUST NOT begin with a '-' or a digit. 'Identity': This Mix node's identity key, represented in ASN.1, and encoded in BASE64. The modulus of this key SHOULD be at least 2048 bits long and no more than 4096 bits long. The exponent of this key MUST be 65537. [XXX: Is there a reason why the exponent is a MUST requirement, and not a SHOULD? - PP] 'Digest': The digest of this descriptor. The value of this entry is unsigned. (See section 2.5) 'Signature': The signed digest of this block, signed by the Identity key. The value of this entry is unsigned. (See section 2.5) 'Published': The time when this block was generated. 'Valid-After': A date. After midnight GMT on this date, this server SHOULD support the operations listed in this descriptor. 'Valid-Until': A date. Until midnight GMT on this date, this server SHOULD support the operations listed in this descriptor. This date MUST be at least one day after the date in Valid-After. 'Packet-Key': The public key used to encode subheaders for Type-III packets. 'Packet-Versions': A comma-separated list of allowable major.minor versions for packets this server will process. In a production network, only one value SHOULD be used for this field. 'Contact': An email address that can be used to contact the administrator of this server. MUST NOT be more than 256 characters. The 'Server' section MAY contain the following entries, at most once each: 'Contact-Fingerprint': Fingerprint of the server administrator's OpenPGP key. MUST NOT be more than 128 characters. 'Comments': Human-readable information about this server. MUST be less than 1024 bytes long. It MUST NOT be necessary to read this information to use the server properly. 'Software': A string description of the software this server is running. MUST be less than 256 characters. Softare SHOULD NOT take any action based on this field, other than to display it. 'Secure-Configuration': A boolean value. If true, the server MUST NOT be running in an insecure operating mode. [XXXX list these modes. Added in Mixminion 0.0.4] 'Why-Insecure': A human-readable string. This string SHOULD be present if and only if Secure-Configuration is 'no'. If present, it SHOULD contain an explanation of why the operating mode is insecure. [Added in Mixminion 0.0.5] [Note: before computing the digest, all implementations MUST normalize CR and CR-LF style newlines to a single NL, and remove any spaces and tabs that may have been introduced at the ends of lines.] If this server accepts incoming MMTP connections, it MAY have an 'Incoming/MMTP' section, with the following entries, exactly once each: 'Version': The string '1.0' 'IP': An IPv4 address, in dotted-quad format. [No longer checked by Mixminion 0.0.8; will no longer be generated by Mixminion 0.0.9.] 'Hostname': A fully qualified hostname, or an IPv4 address in dotted-quad format. 'Port': A TCP port at which IP accepts incoming MMTP connections. 'Protocols': A comma-separated list of the versions of MMTP this server accepts. The 'Incoming/MMTP' section MAY contain any number of entries of the form: 'Allow': AddressPattern 'Deny': AddressPattern If this server supports outgoing MMTP connections, it MAY have an 'Outgoing/MMTP' section, with the following entries, exactly once each: 'Version': The string '1.0' 'Protocols': A comma-separated list of versions of MMTP this server supports for outgoing connections. The 'Outgoing/MMTP' section MAY contain any number of entries of the form: 'Allow': AddressPattern 'Deny': AddressPattern These entries are order-significant; the first one to match wins. The default policy is 'Deny: *'. The 'Testing' section MAY be generated to describe other information about their configuration that may be useful for debugging. Implementations MUST NOT require any specific entries within 'Testing'; implementations also MUST NOT require any specific format for entries that may be present. If this server supports outgoing delivery mechanisms, it MAY have corresponding delivery sections. See 'E2E-spec.txt' for more details on specific types, including SMTP and MBOX. Other services provided by this server SHOULD each have their own section. Note: A server MAY omit some of its capabilities from its descriptor. It is permissible (for example) for a server that supports incoming MMTP connections to omit the Incoming/MMTP section. A server MUST NOT, however, advertise any capabilities it does not support. 3.1. Server Identity Every server descriptor contains two fields that identify the corresponding mix: the Identity public key, and the Nickname. Because only the Mix has the private key corresponding to the Identity key, the identity key works as a unique identifier for the Mix. For user convenience, a mix's Nickname also serves as a unique identifier. Every nickname SHOULD correspond to a single identity key: directory servers and clients SHOULD reject descriptors that use the same nickname as a previously encountered descriptor but change the identity key. All nickname matches MUST be case insensitive. 3.2. Descriptor liveness When choosing between multiple server descriptors for the same Mix that are valid at the same time, implementations SHOULD choose the most recently published descriptor. The interval of time between a descriptor's 'Valid-After' and 'Valid-Until' dates is called its Lifetime. If some descriptor's lifetime is in the past, that descriptor is said to be Expired. If a descriptor's lifetime is all either in the past or contained within the lifetimes of more recently published descriptors for the same server, that descriptor is said to be Superseded. 4. Directory Format 4.1. Multiply-signed format (used in Mixminion 0.0.8) A directory contains a list of Mixminion servers, a statement of which servers are believed to be "good" (operational, reliable, and trustworthy) at a given time, and other information about the network. Each directory is signed by one or more directory servers. A directory MUST contain all of the following, in order: - Zero or more 'Signed-Directory' sections. - A 'Directory-Info' section. - A 'Recommended-Software' section. - Zero or more other unrecognized sections. - Zero or more server descriptors (see section 3 above). Each 'Signed-Directory' section MUST contain the following entries: - 'Directory-Identity' : The Identity key of the directory server that generated this directory. The modulus of this key MUST be between 2048 and 4096 bits long, and the exponent MUST be 65537. - 'Directory-Digest' : The digest of the entire directory, starting with the Directory-Info section. - 'Directory-Signature' : The signature of the directory digest with the directory server's identity key. (A Signed-Directory section is unsigned; see 2.5) The 'Directory-Info' section MUST contain the following entries, in order: - 'Version': The string '1.0' - 'Status': The string "consensus" or the string "vote". Clients MUST refuse to use directories whose Status is "vote". - 'Valid-After' : A date. This directory SHOULD NOT be used before midnight GMT on this date. - 'Valid-Until' : A date. This directory SHOULD NOT be used after midnight GMT on this date. This date SHOULD be exactly one day after the date in 'Valid-After'. - 'Recommended-Servers' : A sorted list of lower-case server nicknames. Items are separated by a comma and a single space. Clients SHOULD NOT depend on servers whose nicknames are not on this list to be reliable or trustworthy. The 'Directory-Info' section MUST contain at least one of the following item for each server who voted on this directory: - 'Voting-Server' : Each item contains a fingerprint, a single space, and a URL base. Each fingerprint is an uppercase hexadecimal-encoded SHA1 hash of the ASN.1 encoding of the directory server's identity key; each URL base MUST be escaped. (See 5.1 below for more information on URL bases.) The items are sorted by fingerprint. The 'Recommended-Software' section MUST contain the following entries, in order: - 'MixminionClient' : A list of up-to-date versions of Mixminion, in ascending order by version. Items are separated by a comma and a single space. If a client is running a version more recent than any on the list, it SHOULD issue a warning. If a client is running a version not on the list, and some version on the list is more recent than the client's version, the client SHOULD issue a warning, and MAY refuse to run. - 'MixminionServer' : A list of up-to-date versions of Mixminion, in ascending order by version. Items are separated by a comma and a single space. Servers should interpret this list as clients interpret 'MixminionClient'. Entries in 'MixminionClient' and 'MixminionServer' are in ascending order by version. Because the version numbering scheme will be different for each implementation, lines within 'Recommended-Software' are implementation- specific. Other implementations of Type-III should generate similar entries in 'Recommended-Software'. [XXXX compatibility for other implementations!] The server descriptors in the directory MUST be sorted by nickname (case-insensitive), then by Valid-After date, then by digest. Each directory MUST include only a single nickname per identity key, and only a single identity key per nickname. 4.1.1. Migration note The format above ("0.3") is not compatible with the older "0.2") format. Therefore, directories for Mixminion 0.0.8 will need to be published to a different URL than for older versions. 4.2. Obsolete format (used before Mixminion 0.0.8.) A directory contains a list of Mixminion servers which are believed to be operational at a given time. A directory MUST contain all of the following, in order: - A 'Directory' section, - A 'Signature' section, - A 'Recommended-Software' section, - One or more server descriptors (see section 3 above). The 'Directory' section MUST contain the following entries: - 'Version': The string '1.0' - 'Published': The time when this directory was generated. - 'Valid-After' : A date. This directory SHOULD NOT be used before midnight GMT on this date. - 'Valid-Until' : A date. This directory SHOULD NOT be used after midnight GMT on this date. This date SHOULD be exactly one day after the date in 'Valid-After'. - 'Recommended-Servers' : A comma-separated list of server nicknames. Clients SHOULD NOT depend on servers whose nicknames are not on this list to be reliable or trustworthy. The 'Signature' section MUST contain the following fields: - 'DirectoryIdentity' : The Identity key of the directory server that generated this directory. The modulus of this key must be between 2048 and 4096 bits long, and the exponent must be 65537. - 'DirectoryDigest' : The digest of the entire directory. The value of this entry is unsigned. (See section 2.5) - 'DirectorySignature' : The signature of the directory digest with the directory server's identity key. The value of this entry is unsigned. (See section 2.5) The 'Recommended-Software' section MUST contain the following entries: - 'MixminionClient' : A comma-separated list of up-to-date versions of Mixminion. If a client is running a version more recent than any on the list, it SHOULD issue a warning. If a client is running a version not on the list, and some version on the list is more recent than the client's version, the client SHOULD issue a warning, and MAY refuse to run. - 'MixminionServer' : A comma-separated list of up-to-date versions of Mixminion. Servers should interpret this list as clients interpret 'MixminionClient'. Entries in 'MixminionClient' and 'MixminionServer' are in decreasing order of preference. Because the version numbering scheme will be different for each implementation, lines within 'Recommended-Software' are version specific. Other implementations of Type-III should generate similar entries in 'Recommended-Software'. 5. Directory Protocols Compliant directory servers MUST provide HTTP URLs to download a current directory or upload a descriptor for inclusion in a directory. 5.1. Retrieving a directory A directory server MUST provide a canonical 'URL base' where material for that directory can be downloaded. Individual documents are published in documents under that directory base. URL bases must end with "/". If a directory server's URL base is "B/", then the following documents are defined: B/ SHOULD contain a human-readable HTML document describing the directory server and its policies. B/current.gz MUST contain a currently valid directory, or one which will be valid 'very soon' [XXXX how soon?], signed by the directory server and as many other directory servers as possible. B/YYYY-MM-DD.gz MUST contain a "consensus" or "opinion"-status directory, for all appropriate dates. (see XXXX NMNM below for more information about voting.) B/YYYY-MM-DD-vote.gz MUST contain a signed "vote"-status directory, for all appropriate dates (see XXXX NMNM below for more information about voting.) All the above documents are compressed with GZIP if their names end with ".gz". Directory servers MAY have other, non-canonical URL bases. Directory servers SHOULD make their identities well-known out of band. 5.2. Publishing a server descriptor A directory server MUST provide an upload URL at "B/upload", where "B/" is its URL base. To upload a descriptor block, a client performs an HTTP POST request to the upload URL, with the server block as the contents of a single parameter, 'desc'. The server MUST reply to an upload with a message of Content-Type text/plain, and contents of the form UploadReply ::= StatusLine MessageLine StatusLine ::= "Status: " Bit EOL Bit ::= '0' | '1' MessageLine ::= "Message: " Value EOL If the upload is successful and the descriptor will be accepted into the directory, the status MUST be 1, and the message MUST be 'Accepted.'. Otherwise, if the upload was successful and the descriptor will not be accepted into the directory, the status MUST be 0, and the message SHOULD be a description of why the server descriptor was not accepted. Finally, if the upload was successful, but the descriptor will only be accepted into the directory when manually approved by the administrator, the status MUST be 1, and the message MUST be a description of the status of the descriptor, and MUST NOT be 'Accepted.'. When a client has a server descriptor to upload, it SHOULD upload it to all the directories it knows about. 6. Generating server descriptors Servers SHOULD generate at least a [[two weeks]] of keys in advance, and SHOULD allow about [[2.5 days]] for newly published keys to appear in the directory. Servers SHOULD continue to accept packets encrypted to old keys at least [[20 hours]] after their published Value-Until date, and SHOULD NOT accept new keys until their published Valid-After date. [XXXX These ranges above are all guesses. -NM] Servers MAY refrain from publishing their keys entirely. When a server's capabilities or configuration changes in such a way as to render a previous server descriptor incorrect, it SHOULD immediately generate a new server descriptor for each of the existing server descriptors it has published, using the same keys as used in the existing published descriptors. To advertise a planned outage, a server SHOULD publish a server descriptor valid over the time of the entire planned outage, with all sections except 'Server' absent. 7. Generating directories Directory servers follow a five-phase process to generate multiply-signed consensus directories. Each phase occurs on a schedule relative to GMT, on a 24-hour cycle. These phases, described in subsequent sections, are: 1. Research and configuration (continual) 2. Voting (must be complete by 23:00) 3. Tabulation (must be complete by 23:30) 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 descriptors on the network, and try to learn about their reliability. Directory servers SHOULD retain, for each mix, all published descriptors it knows that are not expired or superseded. Additionally, directory server administrators SHOULD decide whether given mixes are "trustworthy". Software SHOULD treat all mixes as untrustworthy by default unless approved by administrators. Measuring "reliability" and defining "trustworthiness" are beyond the scope of this document. Administrators must also configure their directory servers to know base URLs and public key fingerprints for all of the directory servers in their "voting clique". All servers in the clique must agree about the members of the voting clique. 7.1.1. Intermediate server lists It is possible that a mix will upload its descriptor to some but not all of the directory servers. When this happens, it is possible for directory knowledge to become fragmented. To prevent this directory servers SHOULD continually publish a list of known server descriptors, concatenated, at B/current-raw-servers.gz , where B/ is the directory server's base URL. (This list has no signatures or additional information from the directory server.) It should list AT LEAST all the server descriptors that the directory server would include in a vote directory, if the directory server had approved every identity. (See 7.2 below for rules.) A directory server MAY download this list from other servers periodically; when it does, it should treat each encountered server descriptor as if it had just been published normally. 7.2. Voting Once per cycle, each directory server decides which mixes it believes should be listed in the directory, and which should be described as "recommended". (A server is "recommended" if it is both "reliable" and "trustworthy".) The directory server then builds and signs a preliminary directory containing all the servers it believes should be listed, all the servers it believes should be recommended, all the software versions it believes should be recommended, and the members of its voting clique. This preliminary directory has status "vote". The "vote" directory is published at a url of the form B/YYYY-MM-DD-vote.gz, where "B/" is the directory server's base URL, and YYYY-MM-DD is the day for which the voted-upon directory _will_ apply (i.e., the day after the vote takes place). The "vote" directory SHOULD be available _before_ 23:00 GMT. If a "vote" directory is late, some or all directory servers may not be able to incorporate its result into their computed consensus directories. 7.3. Tabulation Once per cycle, after votes should be available, each directory server downloads the vote from each other directory server in its voting group. If initial attempts fail, the directory server reattempts to download periodically during the tabulation period. 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. [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. 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: - If there are multiple nicknames for a given identity, do not include any descriptors for that identity. - If half or fewer of the votes include the identity, do not include any descriptors for the identity. [This also guarantees that there will be only one identity per nickname.] - If we are including the identity, then for each distinct descriptor that appears in any vote directory: - Do not include the descriptor if it will have expired on the date the directory will be published. - Do not include the descriptor if it is superseded by other descriptors for this identity. - Do not include the descriptor if it becomes valid more than 30 days in the future. XXXX - Otherwise, include the descriptor. - Include entries in Recommended-Software and Recommended-Servers if and only if they appear in more than half of the vote directories. - Sort all items and descriptors as specified in section 4.1. - Set the Status of the directory to "consensus". 3. Generate and sign the directory, and publish it at "B/YYYY-MM-DD.gz". The signed directory SHOULD be available by 23:30 GMT; if a signed directory is late, other directory servers may not be able to collect its signature in time for publication. 7.4. Signature collection Once per cycle, after publishing a singly signed directory, each directory server downloads signed directories from all the other directory servers in its voting groups. For each signed directory, the directory server checks whether the signed portion is the same as the one it signed for the given day. If so, it affixes all previously unseen Directory-Signature sections from that signed directory to its own signed directory, and publishes the result at "B/YYYY-MM-DD.gz" If the directory server discovers that another directory server in its voting group has signed a different directory, a directory server SHOULD warn its administrator that fragmentation has occurred. 7.5. Publication At the end of each cycle, at 00:00 GMT, each directory server replaces "B/current.gz" with the multiply-signed directory it collected in "B/YYY-MM-DD.gz". 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 warn the user, and respond appropriately (see 8 below). 8. Downloading directories Any client which has not downloaded a directory since before midnight 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 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 Today's alpha code does not publish its version as '1.0'; it uses '0.x' instead (currently '0.2' for Descriptor-Version, '0.2' for pre-0.0.8 Directory Version, '0.3' for post-0.0.8 directory version, and '0.1' for everything else.) Production versions MUST NOT retain backward compatibility with pre-production releases. When generating Recommended-Software entries for Mixminion, we follow the following policies: A development version of Mixminion (pre 1.0) will only be declared obsolete when it is either too insecure or too buggy to use, when backward compatibility is broken, or when a new stable release comes out. Stable releases will be taken off the list only for security or privacy reasons.