On Tue, Aug 4, 2020 at 6:41 PM nusenu <nusenu-lists@xxxxxxxxxx> wrote:
nusenu:
I'll wait until you (Tor developers) decided on the final naming and format
Is there any interest to move this topic forward to come to some decision
in the near future? (before the end of the month)
I don't think that'd be too hard.
Here is a short summary of what opinions I observed for this topic (naming and format
for Ed25519 identities) so far:
Naming proposals for relay Ed25519 identities:
------------------------------------
'v2 fingerprints' (Damian)
"ed25519 identity" or even just "identity" (nickm)
Output format the Ed25519 relay IDs:
------------------------------------
base64 - 43 characters long (nickm)
this is problematic due to the "/" sign (Damian)
hex - 64 characters long (Damian)
"/" is problematic for DirPort urls, GETINFO commands, etc (Damian)
isn't there urlencoding for URLs? (nusenu)
base64urlsafe - 43 characters long (nusenu)
I hope we can agree to use the same format in all places.
How does the decision process looks like in general in the Tor Project?
I think right now Tor uses unpadded base64 in most internal formats,
but it doesn't actually use those in the user interface anywhere, so
we could just use base64urlsafe (per rfc4648 section 5) for the user
interface.
I would be fine with standardizing that for our API, but I'd want to
write a proposal for it first. It wouldn't have to be long. We'd
want to describe other places where we currently use regular base64
for 256-bit keys, and say whether we should/shouldn't accept and emit
url-safe identifiers there instead.
We should specify that there are no spaces, that the padding "="
characters are removed, and that even though the format as given can
handle 43*6==258 bits, the last two bits must be set to 0, since these
are only 256-bit identifiers.
We should also _probably_ specify some canonical encoding for a pair of keys.