aboutsummaryrefslogtreecommitdiff
path: root/proposals/224-rend-spec-ng.txt
diff options
context:
space:
mode:
authorDavid Goulet <dgoulet@torproject.org>2017-01-31 09:39:34 -0500
committerDavid Goulet <dgoulet@torproject.org>2017-01-31 09:39:34 -0500
commit7e807c15aee409b68930a616d0e37b10a6f6f147 (patch)
tree52afb467b63c26d70d600cc2600b983a159f4540 /proposals/224-rend-spec-ng.txt
parent009fd7195a0a302d04b4d7d98b213c69a3d76a7f (diff)
downloadtorspec-7e807c15aee409b68930a616d0e37b10a6f6f147.tar.gz
torspec-7e807c15aee409b68930a616d0e37b10a6f6f147.zip
prop224: Fix tabs issue
Signed-off-by: David Goulet <dgoulet@torproject.org>
Diffstat (limited to 'proposals/224-rend-spec-ng.txt')
-rw-r--r--proposals/224-rend-spec-ng.txt102
1 files changed, 51 insertions, 51 deletions
diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt
index 4a685e5..6f71b32 100644
--- a/proposals/224-rend-spec-ng.txt
+++ b/proposals/224-rend-spec-ng.txt
@@ -2137,80 +2137,80 @@ Appendix E. Managing authorized client data [CLIENT-AUTH-MGMT]
E.1.1. Hidden Service side
- A hidden service that wants to perform client authorization, adds a new
- option HiddenServiceAuthorizeClient to its torrc file:
+ A hidden service that wants to perform client authorization, adds a new
+ option HiddenServiceAuthorizeClient to its torrc file:
- HiddenServiceAuthorizeClient auth-type client-name,client-name,...
+ HiddenServiceAuthorizeClient auth-type client-name,client-name,...
- The only recognized auth-type value is "basic" which describes the scheme in
- section [CLIENT-AUTH]. The rest of the line is a comma-separated list of
- human-readable authorized client names.
+ The only recognized auth-type value is "basic" which describes the scheme in
+ section [CLIENT-AUTH]. The rest of the line is a comma-separated list of
+ human-readable authorized client names.
- Let's consider that one of the listed client names is "alice". In this
- case, Tor checks the "client_authorized_pubkeys" file for any entries
- with client_name being "alice". If an "alice" entry is found, we use the
- relevant pubkeys to authenticate Alice.
+ Let's consider that one of the listed client names is "alice". In this
+ case, Tor checks the "client_authorized_pubkeys" file for any entries
+ with client_name being "alice". If an "alice" entry is found, we use the
+ relevant pubkeys to authenticate Alice.
- If no "alice" entry is found in the "client_authorized_pubkeys" file, Tor
- is tasked with generating public/private keys for Alice. To do so, Tor
- generates x25519 and ed25519 keypairs for Alice, then makes a
- "client_authorized_privkeys/alice.privkey" file and writes the private
- keys inside; it also adds an entry for alice to the
- "client_authorized_pubkeys" file.
+ If no "alice" entry is found in the "client_authorized_pubkeys" file, Tor
+ is tasked with generating public/private keys for Alice. To do so, Tor
+ generates x25519 and ed25519 keypairs for Alice, then makes a
+ "client_authorized_privkeys/alice.privkey" file and writes the private
+ keys inside; it also adds an entry for alice to the
+ "client_authorized_pubkeys" file.
- In this last case, the hidden service operator has the responsibility to
- pass the .key file to Alice in a secure out-of-band way. After the file
- is passed to Alice, it can be shredded from the filesystem, as only the
- public keys are required for the hidden service to function.
+ In this last case, the hidden service operator has the responsibility to
+ pass the .key file to Alice in a secure out-of-band way. After the file
+ is passed to Alice, it can be shredded from the filesystem, as only the
+ public keys are required for the hidden service to function.
E.1.2. Client side
- A client who wants to register client authorization data for a hidden service
- needs to add the following line to their torrc:
+ 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
+ HidServAuth onion-address x25519-private-key ed25519-private-key
- The keys above are either generated by Alice using a key generation utility,
- or they are extracted from a .key file provided by the hidden service.
+ The keys above are either generated by Alice using a key generation utility,
+ or they are extracted from a .key file provided by the hidden service.
- In the former case, the client is also tasked with transfering the public
- keys to the hidden service in a secure out-of-band way.
+ In the former case, the client is also tasked with transfering the public
+ keys to the hidden service in a secure out-of-band way.
E.2. Configuring client authorization using the control port
E.2.1. Service side
- A hidden service also has the option to configure authorized clients
- using the control port. The idea is that hidden service operators can use
- controller utilities that manage their access control instead of using
- the filesystem to register client keys.
+ A hidden service also has the option to configure authorized clients
+ using the control port. The idea is that hidden service operators can use
+ controller utilities that manage their access control instead of using
+ the filesystem to register client keys.
- Specifically, we require a new control port command ADD_ONION_CLIENT_AUTH
- which is able to register x25519/ed25519 public keys tied to a specific
- authorized client.
+ Specifically, we require a new control port command ADD_ONION_CLIENT_AUTH
+ which is able to register x25519/ed25519 public keys tied to a specific
+ authorized client.
[XXX figure out control port command format]
- Hidden services who use the control port interface for client auth need
- to perform their own key management.
+ Hidden services who use the control port interface for client auth need
+ to perform their own key management.
E.2.2. Client side
- There should also be a control port interface for clients to register
- authorization data for hidden services without having to use the
- torrc. It should allow both generation of client authorization private
- keys, and also to import client authorization data provided by a hidden
- service
+ There should also be a control port interface for clients to register
+ authorization data for hidden services without having to use the
+ torrc. It should allow both generation of client authorization private
+ keys, and also to import client authorization data provided by a hidden
+ service
- This way, Tor Browser can present "Generate client auth keys" and "Import
- client auth keys" dialogs to users when they try to visit a hidden service
- that is protected by client authorization.
+ This way, Tor Browser can present "Generate client auth keys" and "Import
+ client auth keys" dialogs to users when they try to visit a hidden service
+ that is protected by client authorization.
- Specifically, we require two new control port commands:
- IMPORT_ONION_CLIENT_AUTH_DATA
- GENERATE_ONION_CLIENT_AUTH_DATA
- which import and generate client authorization data respectively.
+ Specifically, we require two new control port commands:
+ IMPORT_ONION_CLIENT_AUTH_DATA
+ GENERATE_ONION_CLIENT_AUTH_DATA
+ which import and generate client authorization data respectively.
- [XXX how does key management work here?]
- [XXX what happens when people use both the control port interface and the
- filesystem interface?]
+ [XXX how does key management work here?]
+ [XXX what happens when people use both the control port interface and the
+ filesystem interface?]