[or-cvs] Update tor-spec with new EXTEND format and info about certi...

[Nick Mathewson]

Update of /home/or/cvsroot/doc
In directory moria.mit.edu:/tmp/cvs-serv29189/doc

Modified Files:
	TODO tor-spec.txt 
Log Message:
Update tor-spec with new EXTEND format and info about certificate chains

Index: TODO
===================================================================
RCS file: /home/or/cvsroot/doc/TODO,v
retrieving revision 1.124
retrieving revision 1.125
diff -u -d -r1.124 -r1.125
--- TODO	25 Jun 2004 00:29:30 -0000	1.124
+++ TODO	1 Jul 2004 01:34:02 -0000	1.125
@@ -51,9 +51,13 @@
 
       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 @@
         - 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

Index: tor-spec.txt
===================================================================
RCS file: /home/or/cvsroot/doc/tor-spec.txt,v
retrieving revision 1.58
retrieving revision 1.59
diff -u -d -r1.58 -r1.59
--- tor-spec.txt	17 Jun 2004 18:11:31 -0000	1.58
+++ tor-spec.txt	1 Jul 2004 01:34:02 -0000	1.59
@@ -11,7 +11,7 @@
 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 @@
    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 @@
    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: