From 33308845cec54bfc0096b8ea0339a8ff183aa1b1 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Wed, 22 Mar 2023 14:22:28 -0400 Subject: {rend,tor}-spec: clarify linkspec ID multiplicity issues We were previously a bit unclear on how to handle multiple linkspecs of type ed25519, and our spec didn't actually permit Tor's current behavior. Now we say that both Ed25519 ID and Legacy ID linkspecs MUST appear at most once in a list of linkspecs, and that parties SHOULD enforce this. This is "problem 1" on torspec#193. --- tor-spec.txt | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'tor-spec.txt') diff --git a/tor-spec.txt b/tor-spec.txt index 34a3b44..8f30624 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -1128,7 +1128,9 @@ see tor-design.pdf. be listed. Nodes MUST ignore unrecognized specifiers, and MUST accept multiple - instances of specifiers other than 'legacy identity'. + instances of specifiers other than 'legacy identity' and + 'Ed25519 identity'. (Nodes SHOULD reject link specifier lists + that include multiple instances of either one of those specifiers.) For purposes of indistinguishability, implementations SHOULD send these link specifiers, if using them, in this order: [00], [02], [03], @@ -1154,7 +1156,7 @@ see tor-design.pdf. target OR did not prove its ownership of any such identity key. If only one identity key is provided, but the extending OR knows the other (from directory information), then the OR SHOULD also - enforce that key. + enforce the key in the directory. If an extending OR has a channel with a given Ed25519 ID and RSA identity, and receives a request for that Ed25519 ID and a -- cgit v1.2.3-54-g00ecf