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

[minion-cvs] From peter: remove trailing whitespace

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

Modified Files:
	E2E-spec.txt api-spec.txt dir-agreement.txt dir-spec.txt 
	minion-spec.txt nym-spec.txt spec-issues.txt 
Log Message:
From peter: remove trailing whitespace

Index: E2E-spec.txt
RCS file: /home/minion/cvsroot/doc/spec/E2E-spec.txt,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -d -r1.10 -r1.11
--- E2E-spec.txt	12 Sep 2003 15:32:28 -0000	1.10
+++ E2E-spec.txt	1 Oct 2003 22:15:23 -0000	1.11
@@ -92,14 +92,14 @@
 1.1. Terminology
       * "Packet" - A Type III mix packet.  Fixed in size to 32 KB.
       * "Message" - A variable size end-to-end message, transmitted
         from one location from another.  May be larger or smaller
         than a single packet.
       * "Forward message" - A message sent anonymously to a known
       * "Direct reply message" - A message sent to an known recipient,
         with no attempt to maintain sender anonymity.
@@ -112,7 +112,7 @@
       * "Forward encrypted message" - A forward message encrypted to
         the public key of its recipient.
-      * "Corrupted packet" - A packet which has had its payload 
+      * "Corrupted packet" - A packet which has had its payload
         corrupted on the second leg of its path.  [Other forms of
         corruption will result in the message's not being delivered.]
@@ -137,7 +137,7 @@
 2.1.1. Compression
    We define a compression primitive based on ZLIB, as defined in
    RFC-1950 and RFC-1951.  Because these standards describe only a
    message format, and do not mandate a single compression algorithm,
@@ -160,18 +160,18 @@
    from the Gzip team has averred that this is so with all zlib
    versions from 1.0.4 through 1.1.4, but *may* change in some future
    We also define DECOMPRESS as the inverse of COMPRESS: namely, ZLIB
    decompression as described in RFCs 1950 and 1951.  Note that not
    DECOMPRESS is not defined for every sequence of bytes.
 2.1.2. K-of-N fragmentation
    We define a primitive, FRAGMENT, that breaks a K-packet message
    into N>K packets, such that any K of those packets are sufficient
    to reconstruct the original message with high probability.
    FRAGMENT(M,K,N,i) is the i'th such packet.
    We also define a primitive RECONSTRUCT(K,N,P_i1, P_i2,...P_iK) that
    reconstructs the original message.
@@ -182,7 +182,7 @@
    Currently, we use the algorithm described by Luigi Rizzo in several
    papers and implemented in software at
-             http://info.iet.unipi.it/~luigi/fec.html . 
+             http://info.iet.unipi.it/~luigi/fec.html .
    This algorithm has
    several advantages: first, it has freely-available implementations
    in C and Java under a modified-BSD style license.  Second, it runs
@@ -200,7 +200,7 @@
    reconstructed if and only if K packets from each chunk arrive
    intact. Because packet loss is likely to be nonuniformly concentrated
    at specific remailers and links, this is not so dangerous to
-   reliability as it might initially appear. 
+   reliability as it might initially appear.
    [NOTE: I am not happy with this current situation: there needs to
     be _some_ unpatented probabilistic O(N) algorithm out there! -NM]
@@ -213,26 +213,26 @@
            PS: payload sized (fixed)
            EXF: expansion factor (fixed: everyone must use the same EXF,
                                  see below.)
        Let M_SIZE = CEIL(LEN(M) / PS)
        Let K = Min(16, 2**CEIL(Log2(M_SIZE)))
        Let NUM_CHUNKS = CEIL(M_SIZE / K)
        Let M = M | PRNG(Len(M) - NUM_CHUNKS*PS*K)
        For i from 1 to NUM_CHUNKS:
           Let CHUNK_i = M[(i-1)*PS*K : i*PS*K]
        Let N = Ceil(EXF*K)
        For i from 0 to NUM_CHUNKS-1:
          For j from 0 to N-1:
            FRAGMENTS[i*N+j] = FRAGMENT(CHUNK_i, K, N, j)
          End loop
        End loop
        Return FRAGMENTS.
   [If we find an unpatented O(N) algorithm, we use it instead of this
@@ -255,7 +255,7 @@
    turning DIVIDE from an erasure correcting code into a full secret
    sharing encoding: If insufficient packets are received to reconstruct
    the whole message, none of the message can be reconstructed.
 2.2. Generating messages
    When sending a message as packets, a sender follows these steps:
@@ -268,18 +268,18 @@
       3. Annotate each payload with a payload header.  (The payload
          header includes size, integrity, and fragmentation
-      4. According to the type of the message, encode each payload into 
+      4. According to the type of the message, encode each payload into
          a final 28KB paylaod and (possibly) 20-octet decoding handle.
       5. For each payload, select a list of servers to form a path
          through the network.
       6. Using the decoding handle, payload contents, and route for
          each payload, generate a 32KB type III packet.
-      7. Deliver each packet 
+      7. Deliver each packet
    This section will describe steps 1, 2, 3, 4.  Step 5 is described
    more fully in "path-spec.txt".  Steps 6 and 7 are described in
-   "minion-spec.txt".   
+   "minion-spec.txt".
 2.2.1. Packet format
    As described in minion-design.txt, every mixminion packet contains a
@@ -305,28 +305,28 @@
       * Plaintext forward - the handle is unused; its value is random.
       * Encrypted forward - the handle holds the first 20 octets of the
-        RSA-encrypted session key for this packet.  
+        RSA-encrypted session key for this packet.
-      * Reply - the handle (generated by the SURB creator) contains a 
+      * Reply - the handle (generated by the SURB creator) contains a
         random seed used to seed the RNG that generated the master
         secrets for this SURB header. Payload formats
    The payload of every packet, when decrypted, begins with the one of
-   the two following headers.  
+   the two following headers.
    SINGLE-PACKET-MESSAGE Payload:  [Header size is 22 octets]
       (Single-packet message flag) [1 bit: 0]
       (Length of packet contents)  [15 bits]
       (Hash of packet contents)    [20 octets]
    The length field encodes the size of the contents of the packet
-   after compression. 
+   after compression.
    FRAGMENT Header:  [Header size is 47 octets]
       (Multi-packet message flag)       [1 bit: 1]
       (Packet index)                    [23 bits]
       (Hash of remaining fields and packet
@@ -341,7 +341,7 @@
    We define the constants FRAGMENT_HEADER_LEN = 47 and
    To break a message into packets with headers (steps 2 and 3 in 2.2
    above), an implementation follows these steps:
@@ -357,19 +357,19 @@
                             - OVERHEAD
           Let PADDING = Rand(PADDING_LEN)
           Return a singleton payload containing:
               Flag 0 | Int(15,LEN(M_C)) | Hash(M_C | PADDING) | M_C | PADDING
           Let ID = Rand(TAG_LEN)
           Let SZ = Int(32,Len(M_C))
           For every FRAGMENT_i in FRAGMENTS:
              Let PAYLOAD_i = a fragment payload containing:
                 Flag 1 | Int(23,i) | Hash(ID | SZ | FRAGMENT_i ) | ID
                    | SZ | FRAGMENT_i
@@ -465,14 +465,14 @@
    procedure.  To use this method, SURB generators must store a
    separate long-term secret for each identity they wish to associate
    with a chain of SURBs.
    (Client software MUST support multiple identities, and MUST make
    it clear to the user which identity has been associated with each
    incoming SURB.)
    To generate a SURB for a path of length PATH_LEN, using a long-term
    secret SEC:
          Let SEED = a random 159-bit seed.
       Until Hash(SEED | SEC | "Validate") ends with a 0 byte.
@@ -501,7 +501,7 @@
    Message decoders recognize plaintext (singleton or fragment)
    payloads by checking whether the hash fields match the calculated
-   hash of the rest of the packet.  
+   hash of the rest of the packet.
    If a message decoder knows one or more SURB secrets, it then checks
    the decoding handle 'TAG' to see whether Hash(TAG | SEC |
@@ -509,7 +509,7 @@
    decoder generates secrets from TAG | SEC as in SURB generation, and
    successively decrypts the payload with up to MAX_PATH of them,
    checking each time for a plaintext payload.
    If no SURB secrets are known, or if no SURB secrets yield a
    plaintext payload, and the decoder knows one or more secret keys
    SK_i, it then checks whether PK_Decrypt(SK_i, TAG |
@@ -532,7 +532,7 @@
       If P[2:HASH_LEN] = Hash(P[2+HASH_LEN:Len(P)-2-HASH_LEN]):
          SZ = P[0:2]
          Return "Singleton", P[2+HASH_LEN : SZ]
-      Otherwise, 
+      Otherwise,
          Return "Unknown"
    Otherwise, if the first bit of P[0] is 1:
       If P[3:HASH_LEN] = Hash(P[3+HASH_LEN:Len(P)-3-HASH_LEN]):
@@ -560,17 +560,17 @@
          Let P_t = P.
          For j in 0 ... MAX_PATH-1:
             Let P_t = SPRP_Encrypt(STREAM[j * KEY_LEN : KEY_LEN],
-                                   "PAYLOAD_ENCRYPT", 
+                                   "PAYLOAD_ENCRYPT",
             If DECODE_PLAINTEXT_PAYLOAD(P_t) is not "Unknown", return it.
    For all SK_i:
       Let E0 = TAG | P[0:Len(SK_i)-TAG_LEN]
       Let P0 = PK_Decrypt(SK_i, E0).
       If the OAEP padding is valid:
          Let K = P0[0:KEY_LEN]
          Let P0' = P0[KEY_LEN:Len(P0)-KEY_LEN]
-         Let P1 = SPRP_Decrypt(K, "END-TO-END ENCRYPT", 
+         Let P1 = SPRP_Decrypt(K, "END-TO-END ENCRYPT",
                                P[Len(SK_i)-TAG_LEN : Len(P)-Len(SK_i)+TAG_LEN])
          If DECODE_PLAINTEXT_PAYLOAD(P0'|P1) is not "Unknown", return it.
@@ -599,14 +599,14 @@
    When a server receives a plaintext forward packet containing a
    fragment of a message, it should behave as follows:
       - If the server does not support reconstruction, or if the hash
         of the packet is invalid, it drops the packet.
       - From the declared message size of the message, it calculates
         the number of packets it expects.  If this number is higher
         than the maximum number of packets the server is willing to
-        construct, it drops the packet.  
+        construct, it drops the packet.
       - If the server has already logged this message ID as finished,
         it drops the packet.
@@ -668,7 +668,7 @@
    header MUST be "plaintext".
    [XXXX Right now, there's no way to specify an encoding in a
-   message.  Don't worry--you didn't misread. -NM] 
+   message.  Don't worry--you didn't misread. -NM]
 3.1.2. RFC822 headers
@@ -734,20 +734,20 @@
 3.2.2. Formatting: Message body
-  Header encoding is as described in 3.1.2 above.  
+  Header encoding is as described in 3.1.2 above.
   The following headers are allowed:
         "SUBJECT"  (any.  Must be no more than 900 characters long.)
         "FROM"     (any sequence of printing ASCII characters
                     excluding '"', '[', ']', and ':'. )
         "IN-REPLY-TO" (an RFC2822 msg-id)
         "REFERENCES" (a list of RFC2822 msg-ids)
   [XXXX Are msg-ids really what we want? Should we say more?  Should
         we restrict encoding? -NM]
-  Unrecognized or malformatted headers MUST be removed.  
+  Unrecognized or malformatted headers MUST be removed.
 3.2.3. Delivery
@@ -788,7 +788,7 @@
       words, Eve can already tell which messages set their from
       addresses; she gains nothing by learning that those messages
       have chosen an exit node with From support to do so. -NM]
    The "Date" line should be the current date.
    The "In-Reply-To" and "References" lines should be taken verbatim
@@ -814,7 +814,7 @@
    longer than this by a factor of ~1.33.  The value must be at least
    "32".  It MUST contain a "Allow-From" line, containing 'yes' if the
    server allows user-supplied from addresses and 'no' if it does not.
 3.3. SMTP
    The routing type 0x100 corresponds to SMTP (email) delivery.
@@ -834,7 +834,7 @@
       ATOMCHAR ::= Any character in the range hex 21 through hex 7E,
-             excluding '[', ']', '(', ')', '<', '>', '@', ',', '.', 
+             excluding '[', ']', '(', ')', '<', '>', '@', ',', '.',
              ';', ':', '\', and '"'.
       AT ::= '@' (ASCII hex 40)
       DOT ::= '.' (ASCII hex 2E)
@@ -845,7 +845,7 @@
    [XXXX I suspect the above should be "SHOULD NOT." -NM]
 3.3.2. Formatting: Message body
    The message body format is exactly as the MBOX format, as
    described above in 3.2.2.
@@ -854,11 +854,11 @@
    To deliver an SMTP message, an exit node that supports the SMTP
    delivery type SHOULD construct an RFC2822 message as described in
    3.2.3 above, additionally setting the 'To' line to the mailbox
-   given in the message header.  
+   given in the message header.
    Implementations SHOULD allow exit node operators to configure
    additional fields, and to block specific 'To' addresses.
 3.3.4. Server descriptor section
    Servers that support SMTP delivery MAY include a [Delivery/SMTP]
@@ -873,7 +873,7 @@
    longer than this type. It MUST contain a "Allow-From"
    line, containing 'yes' if the server allows user-supplied from
    addresses and 'no' if it does not.
 3.4. Fragments
 3.4.1. Server descriptor section
@@ -885,7 +885,7 @@
    The section, if present, MUST contain a 'Version' entry, with the
    value "1.0".  It also MUST contain a "Maximum-Fragments" line,
    containing the maximum size (in fragments) of a message that the
-   server is willing to reconstruct. 
+   server is willing to reconstruct.
 A.1. Apendix: versioning and alphas

Index: api-spec.txt
RCS file: /home/minion/cvsroot/doc/spec/api-spec.txt,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- api-spec.txt	22 Aug 2003 01:17:59 -0000	1.2
+++ api-spec.txt	1 Oct 2003 22:15:24 -0000	1.3
@@ -42,7 +42,7 @@
 typedef void *(*mix3_allocator)(size_t n);
 typedef void (*mix3_deallocator)(void *ptr);
-void mix3_set_allocator(mix3_allocator allocator, 
+void mix3_set_allocator(mix3_allocator allocator,
                         mix3_deallocator deallocator);
 /* Anything that will be freed by a mix3_* function must be
  * mix3_alloc'd; anything that was alloced by a mix3_* function must
@@ -75,7 +75,7 @@
         /* The operation failed because the arguments given to the
          * function were invalid.
-         */ 
+         */
         /* The operation failed because the directory, server
          * descriptor, message, etc provided was not correctly
@@ -104,13 +104,13 @@
         /* XXXX We need __way__ more error codes.  I don't know  */
 } mix3_status;
-/* Effects: Given a mix3_status code, return a English string. 
+/* Effects: Given a mix3_status code, return a English string.
  * Allocates: nothing.
 const char *mix3_status_string(mix3_status status);
 /* ==================== */
-/* Directories */ 
+/* Directories */
 /* ==================== */
 /* Opaque struct to hold a Type III directory */
@@ -130,7 +130,7 @@
  * approximately -n random servers are chosen.
 typedef struct mix3_pathcomponent {
                MIX3_PC_SWAP } type;
         union {
                 char *name;
@@ -157,7 +157,7 @@
 } mix3_capability_spec;
 /* Struct to specify the destination of a Type III message. */
 typedef struct mix3_address_spec {
                MIX3_ADDR_DROP,  MIX3_ADDR_OTHER, MIX3_ADDR_REPLY, } type;
         union {
                 char *address;
@@ -238,18 +238,18 @@
  * directory that match certain properties.
  * Arguments:
- *    servers_out -- If the function succeeds, *servers_out will be a 
+ *    servers_out -- If the function succeeds, *servers_out will be a
  *        NULL-terminated array of pointers to server descriptors.
  *    byNickname -- If not NULL, the function only yields server
  *        descriptors whose nicknames match byNickname.
  *    byCapability -- If not NULL, the function only yields server
  *        descriptors that have at leas tthe capabilities set in
- *        *byCapability. 
+ *        *byCapability.
  *    validBy -- If not 0, the function only yields server descriptors
  *        that become valid at some time before validBy.
  *    validUntil -- if not 0, the function only yields server
  *        descriptors that do not become invalid before validUntil.
- *  
+ *
  * Allocates: servers_out; it must be freed.
 mix3_status mix3_directory_get_servers(
@@ -284,7 +284,7 @@
 /* === Helper functions for server descriptors. === */
 /* Return a raw field from a server descriptor, by section and field
- * name. 
+ * name.
 const char *mix3_serverdesc_get_field(mix3_serverdesc *desc,
                                       const char *section,
@@ -303,7 +303,7 @@
  *    validate -- If true, check the signature on the descriptor.
  * Allocates: *serverdesc_out, which must be freed with
- *    _mix3_serverdesc_free. 
+ *    _mix3_serverdesc_free.
 mix3_status _mix3_serverdesc_parse(
         mix3_serverdesc **serverdesc_out,
@@ -377,7 +377,7 @@
 /* A structure to specify a message header for a SMTP or NEWS message.
 typedef struct mix3_header_spec {
                MIX3_HEADER_REFERENCES } header;
         char *value;
 } mix3_header_spec;
@@ -402,7 +402,7 @@
  * Allocates: *mix3_payload_out. Each element of *mix3_payload_out[]
  * should be passed to mix3_free, followed by *mix3_payload_out
  * itself.
- *  
+ *
  * XXXX This fails if the message won't all fit into memory with the
  * payloads.  That's probably okay.
@@ -535,13 +535,13 @@
  *        MIX3_WANTREAD or MIX3_WANTWRITE as status.
  * Allocates: *mix3_mmtp_connection, which must be freed with
- *    mix3_mmtp_connection_free. 
+ *    mix3_mmtp_connection_free.
 mix3_status mix3_mmtp_new_connection(
         mix3_mmtp_connection **out,
         mix3_serverdesc *server,
         bool blocking);
-/* XXXX What to do about DNS, if we ever do DNS. */ 
+/* XXXX What to do about DNS, if we ever do DNS. */
 /* XXXX We also need to do something about 'REJECTED' replies. */
@@ -609,7 +609,7 @@
 int mix3_mmtp_get_n_acks(mix3_mmtp_connection *conn);
-/* Renegotiate a key with a connected MMTP server.  Returns as above.   
+/* Renegotiate a key with a connected MMTP server.  Returns as above.
 mix3_status mix3_mmtp_renegotiate(mix3_mmtp_connection *conn);
@@ -671,7 +671,7 @@
 /* Identity of a fragment within a fragmented message */
 typedef unsigned long mix3_fragment_fragment_id;
 /* Return the length of the (compressed) message corresponding to
  * pkt. */
 size_t mix3_decoded_packet_get_length(mix3_decoded_packet *pkt);

Index: dir-agreement.txt
RCS file: /home/minion/cvsroot/doc/spec/dir-agreement.txt,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- dir-agreement.txt	14 Aug 2003 21:25:36 -0000	1.4
+++ dir-agreement.txt	1 Oct 2003 22:15:24 -0000	1.5
@@ -7,7 +7,7 @@
    This is a draft document describing a directory agreement protocol
    for Type III remailers.  If people like it, we'll merge in into
-   Mix3:3 "dir-spec.txt". 
+   Mix3:3 "dir-spec.txt".
    It's substantially identical to what Nick was blathering about at
@@ -21,7 +21,7 @@
    Currently, we have specifications for most of the type III
    directory system, including: server descriptor structure, directory
-   structure, publishing to directories, building directories, 
+   structure, publishing to directories, building directories,
    downloading directories, and using directories.  One critical
    piece remains: directory agreement.
@@ -43,7 +43,7 @@
           which directory helps the attacker mount statistical
           partitioning attacks on the network based on client
           (If users try to avoid this attack by using multiple
           directories, they only make their situation worse: Instead
           of dividing themselves into D possible states of knowledge,
@@ -61,12 +61,12 @@
         an absolute requirement.  In particular, the protocol should
         succeed even when the directory servers do not agree on who is
         a directory server.
       - The protocol should allow old directory servers to shut down,
         and new directory servers to join, but should not allow an
         attacker to control the final directory by signing up a large
         number of directory servers.
       - When the protocol succeeds, it should create a directory
         signed by a large quorum of directory servers.  If at least
         half of the quorum has signed a directory, clients should be
@@ -79,7 +79,7 @@
       - If at least half of the directory servers in a quorum are
         running, cooperative, and able to communicate, then they
         should produce a signed directory.
       - The protocol should discourage social engineering attacks
         aiming to fragment a quorum of directory servers.  Although
         it is impossible to *force* only a single directory to exist
@@ -136,7 +136,7 @@
    Below, I discuss this protocol in more detail.
 1. Terminology
@@ -261,7 +261,7 @@
       and new server descriptors.
    Phase 1: Declarations  (22:00)
       Once a day, at 22:00, every directory server publishes (at some
       well known URL) a signed Declaration.  A Declaration includes:
@@ -295,12 +295,12 @@
       For auditing purposes: Along with their pre-directories,
       directory servers also publish a signed copy of the declarations
       they have used to compute the pre-directory.
    Phase 4: Pre-directories are collected (23:00-23:50)
       Directories collect one another's signed pre-directories as in
       Phase 2.
    Phase 5: A directory is published (00:00)
       Every directory collects the pre-directories from step 4 from
@@ -406,7 +406,7 @@
       - It lists mixes as "recommended" iff they are considered
         reliable by enough members of the quorum and they are
         considered credible by enough members of the quorum.
         [If the quorum has an odd number N members, "enough" is

Index: dir-spec.txt
RCS file: /home/minion/cvsroot/doc/spec/dir-spec.txt,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -d -r1.14 -r1.15
--- dir-spec.txt	4 Sep 2003 16:14:02 -0000	1.14
+++ dir-spec.txt	1 Oct 2003 22:15:24 -0000	1.15
@@ -49,7 +49,7 @@
    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 to provide cover traffic to one another by
    behaving as similarly as possible when choosing paths and servers
@@ -70,14 +70,14 @@
      * 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.  
+     * 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.
@@ -153,10 +153,10 @@
    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
@@ -177,7 +177,7 @@
      - 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.
@@ -204,9 +204,9 @@
             Address ::= '*' | IP OptMask
             OptMask ::= '/' IP |
             IP ::= <an IPv4 dotted quad>
             OptPortSpec ::= | Port | Port '-' Port
        An omitted mask defaults to  '*' is a synonym
        for  An omitted PortSpec defaults to 48099 for
        'allow' entries and 0-65535 on 'deny' entries.
@@ -239,16 +239,16 @@
    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.
    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 be no more than 128 characters.  It MUST contain only
             the characters [A-Za-z0-9_@] and '-'.
         '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
@@ -312,11 +312,11 @@
    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
    If this server accepts incoming MMTP connections, it MAY have an
    'Incoming/MMTP' section, with the following entries, exactly once
         'Version': The string '1.0'
         'IP': An IPv4 address, in dotted-quad format.  [Deprecated but
@@ -338,28 +338,28 @@
         '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
          '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
          'Allow': AddressPattern
          'Deny': AddressPattern
    These entries are order-significant; the first one to match wins.
    The default policy is 'Deny: *'.
@@ -368,18 +368,18 @@
    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
@@ -401,7 +401,7 @@
    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.
@@ -413,28 +413,28 @@
    same server, that descriptor is said to be Superceded.
 4. Directory Format
    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, 
+      - 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.
@@ -454,7 +454,7 @@
    The 'Recommended-Software' section MUST contain the following
      - '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
@@ -493,9 +493,9 @@
 5.2. Publishing a server descriptor
    A directory server SHOULD provide one or more well-known HTTP URLs
-   to publish server descriptors to the directory.  
+   to publish server descriptors to the directory.
    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
@@ -517,13 +517,13 @@
    be accepted into the directory, the status MUST be 0, and the
    message SHOULD be a description of why the server descriptor was not
    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
 6. Generating server descriptors
    Servers SHOULD generate at least a [[two weeks]] of keys in advance,
@@ -548,9 +548,9 @@
    all sections except 'Server' absent.
 7. Generating directories
    Directory servers SHOULD change their directories only at midnight
-   GMT.  
+   GMT.
    For every mix, the directory SHOULD either include no descriptors
    from that mix; or include all of that mix's published descriptors
@@ -563,7 +563,7 @@
    its users anonymity.  A 'reliable' mix is one that delivers packets
    with high probability and reasonable latency.  Directories SHOULD
    include only trustworthy and reliable mixes on their
-   'Recommended-Servers' entry.  
+   'Recommended-Servers' entry.
 8. Downloading directories
@@ -602,7 +602,7 @@
    of length N', and 'random path of random length (E[length]=N)'.
    [This algorithm is implemented in Mixminion 0.0.5]
    The inputs to this algorithm are:
       1) The earliest time at which the path must be valid. (T_Start)
       2) The latest time at which the path must be useable. (T_End)
@@ -631,7 +631,7 @@
    meets these criteria:
       E) Has its nickname the 'Recommended-servers' list.
    Next, the client resolves explicitly specified servers: every
    server specifier with a provided nickname resolves into the
    'current' server descriptor with that nickname.  If there is no
@@ -648,4 +648,4 @@
    specifiers.  The client picks 'preferred' server descriptors at
    random, with replacement, avoiding any sequence of two consecutive
    server descriptors with the same nickname.

Index: minion-spec.txt
RCS file: /home/minion/cvsroot/doc/spec/minion-spec.txt,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -d -r1.13 -r1.14
--- minion-spec.txt	1 Oct 2003 00:29:57 -0000	1.13
+++ minion-spec.txt	1 Oct 2003 22:15:24 -0000	1.14
@@ -108,7 +108,7 @@
        and others, based on the PGP message format, using SMTP for an
        underlying transport.  Also known as the "cypherpunk"
      * Type II - an anonymity service originally designed by Lance
        Cottrell to address the flaws of the Type I system, and
        implemented in the software "Mixmaster".
@@ -118,7 +118,7 @@
      This document uses the terms "MUST", "SHOULD", "MAY", "MUST
      NOT", "SHOULD NOT", and "MAY NOT" as defined in RFC 2119.
      [XXXX is this wise? Observable variation=linkability. -NM]
      * Packet - A 32 kilobyte string transmitted anonymously through
        the Type III remailer network.
@@ -135,7 +135,7 @@
    In this section, we provide an overview of the operations of Type
    III remailers
    [XXXX We need to be more explicit here, or somewhere, about
    crossover points and what exactly is encrypted with what. XXXX]
@@ -182,7 +182,7 @@
       8. The server waits until enough time has passed, and/or enough
          packets have been received.  [A suggested rule is described
          in appendix A.1 below.]
       9. If the server is the final mix on the path, it delivers the
          message to the recipient [as described in section
], else it delivers it to the next mix [as described
@@ -208,7 +208,7 @@
       3. Through some means the recipient delivers the SURBs
          anonymously to the sender, possibly as the contents of a
-         forward message. 
+         forward message.
       4. The sender constructs one or more packets for the recipient
          and inserts them into the network to be delivered, as in
@@ -240,7 +240,7 @@
 3.1.1. Cryptographic primitives
    Implementing a Type III remailer only requires the combination of
    standardized cryptographic primitives. Most third party
    cryptographic libraries or providers should support RSA-OAEP (PKCS#1
@@ -275,7 +275,7 @@
    value will make the decryption look like random bits, we use an
    instance of the LIONESS SPRP, with SHA-1 for a hash and the
    stream described in above.
    Thus, in the notation described below, we encrypt a message M with
    a key K as follows:
            K1 = K
@@ -314,14 +314,14 @@
    ASCII string (a quotation from Thomas Paine):
      "He who would make his own liberty secure, must guard even his
-      enemy from oppression." 
+      enemy from oppression."
-   (In hexadecimal, the hash of P is: 
+   (In hexadecimal, the hash of P is:
     [90 89 60 BC 88 EF 92 B0 9c 58 26 C4 BE 32 B3 34 A7 1C AA 5A].)
    For all public key operations in Type III packets, we use 2048-bit
    keys.  We define:
        PK_OVERHEAD_LEN = 42   (octets added by OAEP padding)
        PK_ENC_LEN = 256       (size of RSA-encrypted data)
@@ -333,12 +333,12 @@
    We use the following function-style notations in describing our
    packet format.
    - Len(A) - The length, in octets, of an octet array A.
    - A[i:j] - If A is an octet array, A[i:j] is a subarray starting at
      octet i with length j.   (Len(A[i:j]) = j)
    - Rand(n) - Generates n random octets by any secure method.
      Successive instances of Rand generate different and uncorrelated
      sequences.  (Len(Rand(n)) = n)
@@ -361,27 +361,27 @@
      Len(PK_Encrypt(PK,M) = PK_ENC_LEN = 256)
    - PK_Decrypt(SK, M) - The private-key decryption of an octet array
-     M using the secret key SK.  
+     M using the secret key SK.
      (0 <= Len(PK_Decrypt(SK,M)) <= PK_MAX_DATA_LEN = 214)
    - PK_Encode(PK) - The ASN.1 encoding of a public key PK.
    - PRNG(K, n) - Uses a cryptographic stream generator to produce n
      octets, using key K.  (Len(K) = KEY_LEN = 16; Len(PRNG(K,n)) = n)
    - Encrypt(K, M) = M ^ PRNG(K,Len(M)) - The encryption of an octet array
      M with our stream cipher, using key K.  (Encrypt(Encrypt(M)) = M.)
-   - SPRP_Encrypt(K, M) - The encryption of an octet array M using our 
-     super-pseudorandom permutation with key K.  
+   - SPRP_Encrypt(K, M) - The encryption of an octet array M using our
+     super-pseudorandom permutation with key K.
      (Len(K) = SPRP_KEY_LEN = 20; Len(SPRP_ENC(K,M)) = Len(M))
    - SPRP_Decrypt(K, M) - The decryption of an octet array M using our
-     super-pseudorandom permutation with key K.  
+     super-pseudorandom permutation with key K.
      (Len(K) = SPRP_KEY_LEN = 20; Len(SPRP_DEC(K,M)) = Len(M))
    - SubKey(K,S) - Derivation of a named sub key, using a master key K
-     (Len(K) = 16) and an aribrary length ASCII String. 
+     (Len(K) = 16) and an aribrary length ASCII String.
      (Len(SubKey(K,S)) = 16)
      SubKey(K,S) = Hash(K, S)[0:16]
@@ -389,8 +389,8 @@
      integer N.
    To improve the readability of our specification, we use the
-   following symbolic constants: 
+   following symbolic constants:
    - HASH_LEN = 20
    - KEY_LEN = 16
    - PK_OVERHEAD_LEN = 42
@@ -441,7 +441,7 @@
        protocol. If a Mix receives a packet with an unrecognized
        version, it must discard that packet.  Note that the major and
        minor version numbers are stored using their binary
-       representations (not the corresponding ASCII codes.) 
+       representations (not the corresponding ASCII codes.)
        (Nodes must advertise in their status blocks what versions of
        the protocol they support; see "dir-spec.txt".)
@@ -467,9 +467,9 @@
    We will refer to the fixed-size part of the subheader structure as:
       FSHS(V, SK, D, RS, RT) = V|SK|D|RS|RT    [MIN_SH = 42 octets]
    We will refer to the entire subheader as:
-      SHS(V, SK, D, RS, RT, RI) = FSHS(V,SK,D,RS,RT) | RI  
+      SHS(V, SK, D, RS, RT, RI) = FSHS(V,SK,D,RS,RT) | RI
            [42+Len(RI) octets] Routing information
@@ -518,7 +518,7 @@
    a server is addressed via a static IPs, it should use a dotted quad
    as their hostname.  As of Mixminion 0.0.7, the types formerly
    associated with *FWD/IPv4 will become unallocated.]
    See 'E2E-spec.txt' for more information about SMTP and MBOX delivery.
 3.2.2. Header Structure
@@ -537,17 +537,17 @@
    be more or less than PK_MAX_DATA_LEN=214 octets long, some of the
    RI field may spill into the stream-encrypted portion, or some of
    the next mix's header may spill into the RSA-encrypted portion.
    These diagrams should help explain:
      1. If the subheader is less than PK_MAX_DATA_LEN octets long, it
         fits into a single RSA encryption along with some of the data
         from the rest of the header.
         Before: (S is the new subheader, H is the existing header material)
-        After: 
+        After:
            (Encrypted with RSA)   (Encrypted with AES)
@@ -569,9 +569,9 @@
    H1 = PK_Decrypt(PK, H[0:PK_ENC_LEN])
    K  = SubKey(H1[2:KEY_LEN], "HEADER SECRET KEY")
    H2 = Encrypt(K, H[PK_ENC_LEN: 2048 - PK_ENC_LEN]
-   // Reads the length of the routing information and extracts the 
-   // sub header. 
+   // Reads the length of the routing information and extracts the
+   // sub header.
    SH = (H1|H2)[0:MIN_SH + H1(38:2)]
    MH = (H1|H2)[Len(SH):2048-Len(SH)]
@@ -579,14 +579,14 @@
    [XXXX writeme]
 3.2.4. Constructing a Type III packet
    The information about how to build packets, headers and SURBs is
    provided for information purposes only, since a pure type III
    remailer server is not required to be capable of creating
    packets. Understanding how packets are created may be beneficial
    for understanding why the remailer processes them in the way
    specified in section 3.2.5.
+ Building a header
    Each type III packet has two headers with identical structure. These
@@ -645,14 +645,14 @@
    PROCEDURE: Create a single header.
-   Inputs: RI_1..RI_n, RT_1..RT_N (addresses of intermediate nodes), 
+   Inputs: RI_1..RI_n, RT_1..RT_N (addresses of intermediate nodes),
            PK_1 .. PK_N (Public keys of intermediate nodes),
            SK_1 .. SK_N (Secret keys to be shared with intermediate nodes),
            R Routing type and information of last header (FWD, DROP,
                SWAP, etc.)
    Output: H (The header)
-   Process: 
+   Process:
      // Calculate the sizes of the subheaders.
      for i = 1 .. N
         // OAEP Padding plus invariant parts plus routing info.
@@ -693,7 +693,7 @@
         SH0 = SHS(V, SK_i, Z(20), len(RI_(i+1)), RT_(i+1), RI(i+1))
         SH_LEN = LEN(SH0)
         H0 = SH0 | H_(i+1)
         EREST = Encrypt(K, REST)
@@ -801,13 +801,13 @@
         If Len(PK_PART) != PK_MAX_ENC_LEN, discard the packet.
         FSHS(V, SK, D, RS, RT) = <extract from PK_PART[0:MIN_SH]>
-        Check that D = Hash(H1[PK_ENC_LEN:HEADER_LEN-PK_END_LEN]), 
+        Check that D = Hash(H1[PK_ENC_LEN:HEADER_LEN-PK_END_LEN]),
              and discard if not.
         Check for replays, as described in
         JUNK_KEY = SubKey(SK, "RANDOM JUNK")
-        H1 = H1[PK_ENC_LEN : 2048-PK_ENC_LEN] | 
+        H1 = H1[PK_ENC_LEN : 2048-PK_ENC_LEN] |
         H1 = H1 ^ PRNG(HEADER_KEY, Len(H1))
@@ -815,7 +815,7 @@
         FULL_H = PK_PART[MIN_SH:Len(PK_PART)-MIN_SH] | H1
         RI = FULL_H[0:RS]
         H1 = FULL_H[RS:Len(FULL_H) - RS]
         H2 = SPRP_Decrypt(SK, "HEADER ENCRYPT",H2)
         P = SPRP_Decrypt(SK, "PAYLOAD ENCRYPT",P)
@@ -836,7 +836,7 @@
    as "RFC822 mailbox") and a correct disposition of P (such as
    "decode and deliver via SMTP").  For more information, see section and 'E2E-spec.txt'.
+ Replay avoidance
    The nodes MUST implement a mechanism to make sure that packets
@@ -872,10 +872,10 @@
 3.3. SURB exchange formats.
    This section describes how to encode SURBs for storage or
-   transmission.  
+   transmission.
    A SURB can be encoded in a standard binary or ASCII format.
    Binary Format:
       Begin Marker: 4 octets
@@ -918,7 +918,7 @@
    To encode a SURB for transport, implementations SHOULD support
    OpenPGP-style ASCII armor, with the header text "BEGIN TYPE III
-   REPLY BLOCK" and a single armor header, "Version: 1.0".   
+   REPLY BLOCK" and a single armor header, "Version: 1.0".
 4. Transport protocol
@@ -961,7 +961,7 @@
    - B invents a DH key and sends a certificate chain containing:
       - a certificate with B's transport public key, signed by B's
-        identity key. 
+        identity key.
       - a self-signed certificate containing B's identity key.
    * A checks that the Hash of the identity key is the same as
@@ -977,7 +977,7 @@
     (Future clients that support more protocols should transmit
     "MMTP ", a list of comma-separated protocol versions, and a CRLF.)
-  * If B is not willing to use any protocol A supports, B closes the 
+  * If B is not willing to use any protocol A supports, B closes the
     B sends "MMTP 1.0", CRLF.  This indicates B's choice of protocol.
@@ -1013,7 +1013,7 @@
      * A sends "SEND", CRLF, M, HASH(M|"SEND") (6 + 32k + 20 octets)
      * B sends "REJECTED", CRLF, HASH(M|"REJECTED") (10 + 20 octets)
        [B must reject a packet if its hash is incorrect; if the
         disk is full, or if for some other reason B cannot accept the
         packet.  Again, implementations should not be distinguishable
@@ -1025,19 +1025,19 @@
   * If a connection persists for longer than 15 minutes, the client
     must initiate key renegotiation.  If it has not, the server must
     close the connection.
    The old keys must be permanently overwritten. Special care should be
-   taken to permanently erase them from the Hard Disk and memory. 
+   taken to permanently erase them from the Hard Disk and memory.
    The standard transport mechanism over which the MixMinion Transfer
-   Protocol talks is TCP over IP. The standard listening TCP port should be 
+   Protocol talks is TCP over IP. The standard listening TCP port should be
    number 48099 (until we register a port with www.iana.org)
    All possible checks should be performed during the transfer protocol
    and if any fail the connection MUST stop and all state MUST
-   be deleted. An error MAY be logged. 
+   be deleted. An error MAY be logged.
 A.1. Appendix: A suggested pooling rule
@@ -1047,7 +1047,7 @@
    to flooding attacks.  Implementors are strongly encouraged to use
    this algorithm, or another equally robust against active and
    passive attacks.  (Be sure to read \cite{batching-taxonomy}. [XXXX
-   Ref]) 
+   Ref])
    PROCEDURE: Choose sets of messages to transmit ("Cottrell-style batching")
@@ -1073,7 +1073,7 @@
       Transmit the selected messages.
    3. Repeat indefinitely.
 A.2. Appendix: Backward compatibility with Type II remailers
    In order to share anonymity sets with Type III remailers while
@@ -1082,7 +1082,7 @@
    Nodes that accept both type II and type III may advertise the fact
    in their server descriptor by including a section of the form:
          Address: (type II remailer's email address)
          Key: (type II key)

Index: nym-spec.txt
RCS file: /home/minion/cvsroot/doc/spec/nym-spec.txt,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- nym-spec.txt	28 Jul 2003 01:03:55 -0000	1.3
+++ nym-spec.txt	1 Oct 2003 22:15:24 -0000	1.4
@@ -202,9 +202,9 @@
 1.3.1. Non-goals
    The following properties are *not* goals or requirements of this
-   protocol. 
+   protocol.
-      - Full transport neutrality.  
+      - Full transport neutrality.
         (Although this protocol does not require a Type III mix
         network specifically, it assumes that its underlying transport
@@ -218,7 +218,7 @@
       - Minimal nymserver storage requirement
         (This protocol assumes that nymservers will have to devote a
         certain amount of space to each nym in order to store SURBs
         (under ordinary load) and pending messages (under high load).
@@ -256,7 +256,7 @@
      - To allow the nymserver to communicate back to the anonymous
        nymholder, the nymholder provides the nymserver with a stock of
-       SURBs, and replenishes them periodically. 
+       SURBs, and replenishes them periodically.
        (Because the nymholder uses a separate SURB identity secret for
        each pseudonym it generates, it can distinguish reply messages
@@ -343,7 +343,7 @@
             A 'sent' tristate: "Nothing sent", "Synopsis-sent", "Sent-In-Full".
             A time of receipt.
-      - A set of SURBs 
+      - A set of SURBs
 2.2. Processing incoming emails
@@ -375,7 +375,7 @@
               Anytime delivery to the nymserver fails, bounces should
               also be sent back as per the SMTP server's policies.  I
               think a nymserver will probably be some kind of local
-              delivery agent.  
+              delivery agent.
@@ -520,13 +520,13 @@
      Let M_C = COMPRESS(M).
      Let PADDING_LEN = CEIL(LEN(M_C)/P) - LEN(M_C).
      Let M_P = M | Z(PADDING_LEN).
      Let K = R(16).
      Let M_Enc = SPRP_Encrypt(K, "", M_P)
      Let RSA_LEN = Len(PK_nym) - OAEP_OVERHEAD - 16
      Let RSA_PART = PK_Encrypt(PK_nym, K | M_Enc[0:RSA_LEN])
-     Return RSA_PART | M_Enc[RSA_LEN:Len(M_Enc)-RSA_LEN] 
+     Return RSA_PART | M_Enc[RSA_LEN:Len(M_Enc)-RSA_LEN]
    For efficiency reasons, a nymserver tries to encrypt several
    synopses at once, so that zlib can compress them effectively.
@@ -535,7 +535,7 @@
    between forward security (which would mandate encrypting each
    synopsis as soon as possible) and between efficiency and
    traffic-analysis resistance (which would mandate minimizing the
-   number of packets sent between client and server).  
+   number of packets sent between client and server).
    We strike the following compromise: a nymserver encrypts synopses
    for a user whenever it has eight or more pending synopses to
@@ -554,7 +554,7 @@
    synopses the message ID of every synopsis, in order, contained
    therein.  It can only delete the set of synopses when it has
    deleted every corresponding email.)
 4.3. Control message format: messages to the nymserver
    This section describes the control messages sent from the
@@ -566,7 +566,7 @@
    All of the control messages described below follow the following
             SIG    Signature             (PK_LEN=256 octets)
             NL     Nym Length            (1 octet)
@@ -615,7 +615,7 @@
    empty (0-octet) nym, and should be signed with the identity key
    given in the NEWPK command.  The nymserver replies with a CREATED
    command, which the nymholder confirms with a CREATE2 command.)
    [XXXX specify a proof-of-work system.]
 4.3.2. CREATE2 [0x01]
@@ -671,7 +671,7 @@
    unencoded.  When the server delivers the email, it adds a From
    line with the correct nym mailbox, and sets the name as given in
    the headers.
 4.3.6. GET [0x05]
    A GET command requests that the server transfer a set of emails to
@@ -743,7 +743,7 @@
    All of the control messages described below follow the following
           Sequence of:
             CT    Command type      (1 octet)
             CS    Command data size (3 octets)
@@ -757,7 +757,7 @@
    of the size of the immediately following CD field.
    The following values for CT are recognized:
-        0x00 : CREATED  (Acknowledge a new nym) 
+        0x00 : CREATED  (Acknowledge a new nym)
         0x01 : STATUS   (Acknowledge messages and describe status)
         0x02 : SUMMARY  (Describe pending emails)
         0x03 : MSGS     (Send emails to the client)
@@ -813,14 +813,14 @@
    A SUMMARY command has the following body structure:
      VALID_BF Bitfield: which entries in ES have an email?   (2 octets)
-     ES       Encrypted set of synopses.              
+     ES       Encrypted set of synopses.
                                      (variable length; rest of command)
    The LSB in Valid_BF corresponds to the first synopsis in ES, and so
 4.4.4. MSG [0x03]
    A MSG command relays an email to the client.
    The body of MSG commands have the following structure.
@@ -845,7 +845,7 @@
 4.4.6. ERROR [0x05]
      NONCE  Nonce from client message; Z(20) if none.  (20 octets)
-     ERROR  English-language error message             
+     ERROR  English-language error message
                                 (variable length; rest of command)
 5. Filtering and abuse prevention

Index: spec-issues.txt
RCS file: /home/minion/cvsroot/doc/spec/spec-issues.txt,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -d -r1.6 -r1.7
--- spec-issues.txt	4 Sep 2003 16:14:02 -0000	1.6
+++ spec-issues.txt	1 Oct 2003 22:15:24 -0000	1.7
@@ -38,7 +38,7 @@
    2.4.     Abuse prevention
    2.5.     Path selection in non-freeroute networks -- RESOLVED, NEED SPEC
    2.6.     News -- RESOLVED, NEED SPEC
-   2.7.     PKI bootstrapping 
+   2.7.     PKI bootstrapping
    2.8.     Multiple recipients
    2.9.     Plaintext payload versioning
    3.       Issues in MIX3:3: 'dir-spec.txt'
@@ -142,7 +142,7 @@
    [3Aug: Let's not do hashcash; Nick will write why in FRS.  Neglect
       multiplier issues for now.]
 2. Issues in MIX3:2: 'E2E-spec.txt'
 2.1. Mail gateways
@@ -168,7 +168,7 @@
    way to send multi-part messages.
    This functionality *may* take the format of a canonical subset of
-   MIME, but Lucky thinks that such a thing would drive us into a 
+   MIME, but Lucky thinks that such a thing would drive us into a
    Lovecraftian state of madness.
    [3Aug: Canonicalize encodings; allow types.  PGP-mime is "hard".]
@@ -194,7 +194,7 @@
    Right now, we have some vague ideas about users emailing admins to
    get themselves blacklisted.  This should be specified and
-   automated.  
+   automated.
    Additionally, there are probably some other means of preventing
    abusive behavior.  If these don't make it into the specification,
@@ -251,9 +251,9 @@
 2.9. Plaintext payload versioning
    We should burn a byte or two for a version number on plaintext
-   payloads.  This way, we have some hope of changing to a better 
+   payloads.  This way, we have some hope of changing to a better
    fragmentation algorithm in the future, or what have you.
    Doing this doesn't break the key property that forward payloads
    can be recognized as okay, but that corrupt payloads, reply
    payloads, and encrypted payloads are indistinguishable except to
@@ -346,7 +346,7 @@
          (mixes knowing about directory servers). This way one can run
          independently a directory server, without any collaboration
          from the mix network (other than the ability to request info).
          Let's not forget that the mixes *sign* their information with
          a long term key, therefore after you establish that you trust
          a signing key to belong to an honest server, the operation of
@@ -358,7 +358,7 @@
          use will ruin its anonymity. On the other hand if key updates
          are not frequent, then the client can slowly update its
          database in the background.
          Even more possibilities open up if each mix server give on
          request not only their information but also what they think
          the state of other servers, they have contacted in the past,
@@ -368,13 +368,13 @@
          orthogonal issue, but once it is decided the updated
          information could flow very quickly. (this is in fact a gossip
          These are the reasons why I think it might be a good idea to
          have automatic on request information from servers. -GD]
         [Hm.  You may have a point.  I'm still going to suggest that we
          do not do this yet, for a few reasons.
          First, we need a way for servers to publish their descriptors
          to directory servers.  (Otherwise, a directory server couldn't
          learn about new servers for the first time.)  In other words,
@@ -382,16 +382,16 @@
          directory servers may or may not need a pull mechanism: we do
          not yet have a design that requires this.  Let's not build it
          till we have a use for it.
          Second, it's a bit tricky to specify *which* descriptor a
          server should return.  Today's?  Tomorrow's?  All the ones it
          knows about?
          Third, (this is a variant of 'First') because client use of
          this feature is prone to misuse, we should only provide it to
          clients wrapped in some safe mechanism.  That safe mechanism
          has yet to be specified.
          Therefore, I'm going to suggest that we call this feature
          possibly desirable... but that we should first design
          directories or whatever other node discovery mechanisms *may*
@@ -415,7 +415,7 @@
    Finally, there may be some value in allowing server S1 and server S2
    with the same administrator to also share the same set of keys, thus
    forming a single 'virtual server'.
    [PARTIALLY RESOLVED 3Aug: Treat twins as separate for traffic
      purposes, but don't do adjacently.  Don't do jurisdictions until
      we can either verify them, or show that they are beneficial even
@@ -437,7 +437,7 @@
    standardized, though they would not form a part of any of the
    current specification documents.
-4.1. RFC822-style interface 
+4.1. RFC822-style interface
    It'd be nice to have a standard way to feed a single text file to
    a CLI and get a message sent.