Switch to single-file-per-client client auth UX. #23
Conversation
| authenticate Alice. | ||
|
|
||
| If no "alice.keys" file is found, Tor is tasked with generating Alice's | ||
| keypair. To do so, Tor generates x25519 and ed25519 keypairs for Alice, |
There was a problem hiding this comment.
Does the service need to generate both keypairs? What if that client is enabled in desc auth but not in intro auth (via HiddenServiceAuthorizeClient)?
There was a problem hiding this comment.
In that case the service would need to indeed generate only the desc key.
I didn't end up describing the standard/desc/intro auth distinction in the spec patch because it would get too complex. Perhaps we should do it before proceeding tho.
|
Do we still want to support three authtype keywords (desc, intro, and standard)? |
| ed25519 private 66c1a77104d86461b6f98f73acf3cd229c80624495d2d74d6fda1e940080a96b | ||
| """ | ||
|
|
||
| E.1.3. Client side | ||
|
|
||
| A client who wants to register client authorization data for a hidden service | ||
| needs to add the following line to their torrc: | ||
|
|
||
| HidServAuth onion-address x25519-private-key ed25519-private-key |
There was a problem hiding this comment.
Do we want to put the keyword before the key like HidServAuth onion-address x25519 [x25519-private-key] ed25519 [ed25519-private-key] ?
There was a problem hiding this comment.
Might be a good idea I guess.
|
|
||
| Here is a suggested scheme for "alice.keys" for the latter scenario: | ||
| """ | ||
| alice |
There was a problem hiding this comment.
Why do you need a name here? I think the name is already in the filename
There was a problem hiding this comment.
Yeah might not be necessary indeed. I just wanted to make it clearer, and also make the filename contents self-explanatory.
|
Obsoleted by PR #33. |
No description provided.