Update tor-spec with new EXTEND format and info about certificate chains

svn:r1995

diff --git a/doc/TODO b/doc/TODO
index 1f5c9d66ccaf84e4f46e9c5988bea2637b04153b..47a1b0bffca92299597c796793b3115ca736d2dd 100644 (file)
--- a/doc/TODO
+++ b/doc/TODO
@@ -51,9 +51,13 @@ NICK  pre1:
 
       pre2:
         - refer to things by key:
-          - extend cells need ip:port:identitykeyhash.
+          o extend cells need ip:port:identitykeyhash.
+         . Lookup routers and connections by key digest; accept hex
+            key digest in place of nicknames.
+          - Audit all uses of lookup-by-hostname and lookup-by-addr-port
+            to search by digest when appropriate.
           - also use this in intro points and rendezvous points, and
-            hidserv descs.
+            hidserv descs.  [XXXX This isn't enough.]
           - figure out what to do about ip:port:differentkey
 ARMA    - ORs connect on demand. attach circuits to new connections, keep
           create cells around somewhere, send destroy if fail.
@@ -61,6 +65,7 @@ ARMA    - ORs connect on demand. attach circuits to new connections, keep
         - running-routers list refers to nickname if verified, else
           hash-base64'ed.
 
+
       pre3:
         - users can set their bandwidth, or we auto-detect it:
           - advertised bandwidth defaults to 10KB

diff --git a/doc/tor-spec.txt b/doc/tor-spec.txt
index d9940bc9c8f046a8db8e0f91953bf18a16512b3a..ec543cc72f5a28eb7c812d2e89306cb5cbbf9a40 100644 (file)
--- a/doc/tor-spec.txt
+++ b/doc/tor-spec.txt
@@ -11,7 +11,7 @@ This is not a design document; most design criteria are not examined.  For
 more information on why Tor acts as it does, see tor-design.pdf.
 
 TODO: (very soon)
-      - EXTEND cells should have hostnames or nicknames, so that OPs never
+      X EXTEND cells should have hostnames or nicknames, so that OPs never
         resolve OR hostnames.  Else DNS servers can give different answers to
         different OPs, and compromise their anonymity.
          - Alternatively, directories should include IPs.
@@ -68,13 +68,19 @@ TODO: (very soon)
    support any suite without ephemeral keys, symmetric keys of at
    least 128 bits, and digests of at least 160 bits.
 
-   An OR always sends a self-signed X.509 certificate whose commonName
-   is the server's nickname, and whose public key is in the server
-   directory.
+   An OR always sends two-certificate chain, consisting of a self-signed
+   certificate containing the OR's identity key, and of a second certificate
+   using a short-term connection key.  The commonName of the second
+   certificate is the OR's nickname, and the commonName of the first
+   certificate is the OR's nickname, followed by a space and the string
+   "<identity>".
 
-   All parties receiving certificates must confirm that the public
-   key is as it appears in the server directory, and close the
-   connection if it is not.
+   All parties receiving certificates must confirm that the identity key is
+   as expected.  (When initiating a connection, the expected identity key is
+   the one given in the directory; when creating a connection because of an
+   EXTEND cell, the expected identity key is the one given in the cell.)  If
+   the key is not as expected, the party must close the connection if it is
+   not.
 
    Once a TLS connection is established, the two sides send cells
    (specified below) to one another.  Cells are sent serially.  All
@@ -169,10 +175,18 @@ TODO: (very soon)
    The relay payload for an EXTEND relay cell consists of:
          Address                       [4 bytes]
          Port                          [2 bytes]
+         Public key hash               [20 bytes]
          Onion skin                    [186 bytes]
 
    The port and address field denote the IPV4 address and port of the
-   next onion router in the circuit.
+   next onion router in the circuit; the public key hash is the SHA1 hash of
+   the ASN1 encoding of the next onion router's identity key.
+
+   [XXXX Before 0.0.8, EXTEND cells did not include the public key hash.
+   Servers running 0.0.8 distinguish the old-style cells based on the length
+   of payloads.  Clients running 0.0.8 check for servers version 0.0.7 or
+   later, and send them the old-style EXTEND cells.  In a future release,
+   old-style EXTEND cells will not be supported.]
 
    The payload for a CREATED cell, or the relay payload for an
    EXTENDED cell, contains: