Re: [tor-dev] [RFC] control-spec: Specify add/remove/view client auth commands (client-side).

[meejah <meejah@xxxxxxxxx>]

Mark Smith <mcs@xxxxxxxxxxxxxxxxx> writes:

> 2. For VIEW_ONION_CLIENT_AUTH it would be nice if the HSAddress
> parameter was optional.  We may want to build an interface that allows
> users to see all of their keys and choose which ones to remove, etc.

A few random points:

I like dgoulet's naming, with "ONION_CLIENT" up front.

Why do we need VIEW (with the private keys) at all? (I'm thinking
e.g. when multiple controllers are connected). If we do need a "view"
command, maybe it should only show the key-IDs (and not the actual
private keys)? This, then, would either make ClientName= non-optional,
or the ADD command should return the name of the key.

It might be less confusing to read the spec if you replaced "tells the
server" with "tells tor" or "tells the connected Tor".

Further to Mark's question earlier, I think the spec should say
more about where/how long these keys will be stored.



Since implementers seem to want control of their keys for service-side
things, I would imagine the same will be true on the client-side -- that
is, an option for "ephemeral" in the sense that "Tor stores these only
in memory".

FWIW, the (current) implementation in txtorcon basically encourages an
approach where you keep the keys "in Tor" for as little time as
possible. You *can* add them permanently, but the "nice" API is a
context-manager, so you'd have code somewhat like this:

    tor = await txtorcon.connect(...)
    async with tor.onion_authentication("http://timaq4ygg2iegci7.onion/";, "token-blob"):
        agent = tor.web_agent()
        resp = await agent.request(b'GET', "http://timaq4ygg2iegci7.onion/";)
        body = await readBody(resp)
    # here, auth is removed from tor as we leave the context-manager

-- 
meejah
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev