Specifically, you can look at the directory to see if somebody is
lying about a relay (mismatched IDs, etc), but you can't modify
the list of linkspecs.
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.
I found src/lib/encoding/binascii.[ch] in the C Tor codebase.
It has
#define BASE32_CHARS "abcdefghijklmnopqrstuvwxyz234567"
The function "base32_encode" says "Implements base32 encoding as in
RFC 4648.". Now, that RFC says that it's supposed to be padded unless
explicitly stated otherwise. However, the padding is pointless and
neither our "base32_encode" nor our "base32_decode" seem to implemnet
it.
I hope that we are using the same base32 encoding everywhere, but have
not checked.
These new names are the ones used in arti's hsdir_ring.rs and make a
lot more sense than calling one of them the "directory" index and
the other just the "index".
In C Tor these are calculated by functions called
hs_build_hs_index
hs_build_hsdir_index
That might be a reason *not* to accept this change. Or it might be a
reason to change the C Tor code.
If we don't change the names in the spec the Arti function names
should change.
These names are slightly shorter and a bit more descriptive IMO, and
now (when they are still fresh) is the best time to rename these
keys.
`hs_intro_tid` becomes `hs_ipt_sid`: It is a _session identifier_
key used with an _introduction point_. Using `ipt` here emphasizes
that it is not part of the introduction _handshake_.
`hs_intro_ntor` becomes `hss_ntor`. The extra "s" means it is owned
by the service. Renaming "intro" here removes the implication that
it is held by or used by the introduction point.
`onion_ntor` becomes `ntor`: There is no such thing as an ntor key
that is not an onion key.
It looks like C tor doesn't include a final newline in the middle
layer of its onion service descriptors. That made arti reject them
the first time I tried to parse one! Here I document this behavior,
and tell other implementations what to do.
* The syntax `IN [a,b]` means that a and b are the only valid options,
which isn't what we want to say here.
* I'm changing the hostname tag to 0, which is the same as we have for
RESOLVED cells.
* Introduce the notion of Argument, which is relied on in the
rest of the document, but not defined here formally.
Spec changes implied by this diff:
* Forbid the arguments from containing form feeds, carriage returns,
and vertical tabs.
* Forbid trailing whitespace after the last argument. I'm not sure
whether this is correct, but it seems anomalous to permit it for
only for keyword lines with arguments, and not anywhere else.
