rfc: Clarify key access

Signed-off-by: Alexander Simmerl <a.simmerl@gmail.com>

docs/rfc/0696-p2p-node.adoc

@@ -60,8 +60,7 @@ accessible by the logged-in user (typically `$XDG_RUNTIME_DIR`), and have
 permissions `0700` by default. Per-service socket paths are considered "well
 known".
 
-RPC calls over those sockets use _CBOR_<<cbor>> for their payload encoding. As
-This conversation was marked as resolved by kim
+RPC calls over those sockets use <<cbor, CBOR>> for their payload encoding. As
 incremental decoders are not available on all platforms, CBOR-encoded messages
 shall be prepended by their length in bytes, encoded as a 32-bit unsigned
 integer in network byte order.
@@ -176,14 +175,14 @@ _TODO_
 === Supervision
 
 Process supervision SHOULD be deferred to established system level service
-managers i.e. _systemd_<<systemd>> and _launchd_<<launchd>> for Linux and macOS
-respectively. To support both long-running as well as ad-hoc usage the daemon
-implementation SHALL be equipped with the ability to detect and read the
-information from its environment necessary to determine if it has been activated
-via socket. When binding to a socket it SHALL use the file descriptors provided
-by the init process. If none are provided it SHALL assume long-running operation
-and SHALL bind to the well-known path on a UNIX domain socket in mode
-`SOCK_STREAM` under Linux:
+managers i.e. `<<systemd>>` and `<<launchd>>` for Linux and macOS respectively.
+To support both long-running as well as ad-hoc usage the daemon implementation
+SHALL be equipped with the ability to detect and read the information from its
+environment necessary to determine if it has been activated via socket. When
+binding to a socket it SHALL use the file descriptors provided by the init
+process. If none are provided it SHALL assume long-running operation and SHALL
+bind to the well-known path on a UNIX domain socket in mode `SOCK_STREAM` under
+Linux:
 
   $XDG_RUNTIME_DIR/radicle/<srv>-<peer-id>.sock
 
@@ -228,17 +227,25 @@ i.e. CLI.
 
 _TODO_: Outline binary options surface, maybe including file based configuration.
 
-== Key Management
+== Key Access
 
-_TODO_
+Access to key material SHALL be done through the facilities provided by
+`<<radicle-keystore>>`. Except for debug/development purpose this SHOULD be
+limited to the use of the `ssh-agent` expected to land in
+`<<rk-17, radicle-keystore#17>>`.
+
+The author assumes that the `rad` CLI provides functionality to manage keys on a
+per profile basis including adding them to a running ssh-agent.
 
 [bibliography]
 == References
 
 * [[[cbor]]] https://datatracker.ietf.org/doc/html/rfc8949
 * [[[cddl]]] https://datatracker.ietf.org/doc/html/rfc8610
 * [[[launchd]]] https://en.wikipedia.org/wiki/Launchd
+* [[[radicle-keystore]]] https://github.com/radicle-dev/radicle-keystore/
 * [[[systemd]]] https://systemd.io/
+* [[[rk-17]]] https://github.com/radicle-dev/radicle-keystore/pull/17
 * [[[RFC2219]]] https://datatracker.ietf.org/doc/html/rfc2119
 * [[[RFC8174]]] https://datatracker.ietf.org/doc/html/rfc8174
 * [[[RFC8610]]] https://datatracker.ietf.org/doc/html/rfc8610