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

svn:r1995

1 files changed, 22 insertions, 8 deletions

diff --git a/doc/tor-spec.txt b/doc/tor-spec.txt
index d9940bc9c8..ec543cc72f 100644
--- 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: