tor-spec: Extends accept all-zero ed25519 keys

The spec gives conficting advice about all-zero ed25519 keys in extends.
Resolve this conflict by documenting tor's current behaviour.

Also move a sentence about circuit IDs, so it's closer to the associated
paragraph.

1 files changed, 14 insertions, 9 deletions

diff --git a/tor-spec.txt b/tor-spec.txt
index 6881436..fa6026d 100644
--- a/tor-spec.txt
+++ b/tor-spec.txt
@@ -1333,15 +1333,20 @@ see tor-design.pdf.
 
    When an onion router receives an EXTEND2 relay cell, it sends a CREATE2
    cell to the next onion router, with the enclosed HLEN, HTYPE, and HDATA
-   as its payload.
-
-   As special cases, if the EXTEND/EXTEND2 cell includes a legacy
-   identity, identity fingerprint, or Ed25519 identity of all zeroes, or
-   asks to extend back to the relay that sent the extend cell, the
-   circuit will fail and be torn down. The initiating onion router
-   chooses some circID not yet used on the connection between the two
-   onion routers.  (But see section 5.1.1 above, concerning choosing
-   circIDs.)
+   as its payload. The initiating onion router chooses some circID not yet
+   used on the connection between the two onion routers. (But see section
+   5.1.1 above, concerning choosing circIDs.)
+
+   As special cases, if the EXTEND/EXTEND2 cell includes a legacy identity, or
+   identity fingerprint of all zeroes, or asks to extend back to the relay
+   that sent the extend cell, the circuit will fail and be torn down.
+
+   Ed25519 identity keys are not required in EXTEND2 cells, so all zero
+   keys SHOULD be accepted. If the extending relay knows the ed25519 key from
+   the consensus, it SHOULD also check that key. (See section 5.1.2.)
+
+   If an EXTEND2 cell contains the ed25519 key of the relay that sent the
+   extend cell, the circuit will fail and be torn down.
 
    When an onion router receives a CREATE/CREATE2 cell, if it already has a
    circuit on the given connection with the given circID, it drops the