[tor-dev] Proposal 284: Hidden Service v3 Control Port

[meejah]

David Goulet <dgoulet at ev0ke.net> writes:

Hi David,

Overall looks good! A few comments inline:

>      "onions/{current,detached}"
>        No change. This command can support v3 hidden service without changes
>        returning v3 address(es).

Does the control-spec need a note pointing out that you might get some
"longer" (v3) addresses?

> 3.1.3. ADD_ONION
>
>    For this command to support version 3, new values are added but the syntax
>    is unchanged:
>
>      "ADD_ONION" SP KeyType ":" KeyBlob
>                  [SP "Flags=" Flag *("," Flag)]
>                  1*(SP "Port=" VirtPort ["," Target])
>                  *(SP "ClientAuth=" ClientName [":" ClientBlob]) CRLF
>
>    New "KeyType" value to "ED25519-V3" which identifies the key type to be a
>    v3 ed25519 key.
>
>    New "KeyBlob" value to support the new "ED25519-V3", if specified, will
>    generate a new ed25519 private key.

This might need a couple more details; as-is ADD_ONION can take
"NEW:BEST" (which should now return a v3 service?) or "NEW:ED25519-V3"
for explicitly asking for a V3 key, or "ED25519-V3:<56 base32 chars>"
for adding an already-existing v3 service.

>    Because client authentication is not yet implemented, the "ClientAuth"
>    field is ignored as well as "Flags=BasicAuth".

I think these should generate a 500-level error (if used for a v3
service) instead of being ignored. That is, if you try to use auth with
v3, you get an error.

>    For this event to support vesrion 3, one optional field and new
>    values are added:

I echo Damian's comments on the positional-arg; making it [SP
"DescriptorID=" ] or similar (i.e. an optional kwarg) would mean easier
later extending and also it *should* then "just work" with most
controller libs already at least as far as parsing goes (because
controller libs in general have to accept new, unknown kwargs).


The rest all sounds good to me!

thanks,
meejah