update man pages

1 files changed, 375 insertions, 0 deletions

diff --git a/manpages/taler-exchange-offline.1.rst b/manpages/taler-exchange-offline.1.rst
new file mode 100644
index 00000000..a441f498
--- /dev/null
+++ b/manpages/taler-exchange-offline.1.rst
@@ -0,0 +1,375 @@
+taler-exchange-offline(1)
+#########################
+
+.. only:: html
+
+   Name
+   ====
+
+   **taler-exchange-offline** - perform operations with exchange offline master private key
+
+Synopsis
+========
+
+**taler-exchange-offline**
+[**-h** | **––help**]
+[**-v** | **––version**]
+[SUBCOMMANDS]*
+
+
+Description
+===========
+
+**taler-exchange-offline** is a command line tool to interact with the Taler
+exchange's master private key. Most operations of this tool require access to
+the exchange’s long-term offline signing key and should be run in a secure
+(offline) environment under strict controls.  The tool takes a list of
+subcommands as arguments which are then processed sequentially.
+
+The tool includes two subcommands to interact with the *online* exchange's
+REST APIs.  The "download" subcommand downloads the future public keys from the
+running exchange.  The resulting data serves as input to the "sign" and "show"
+subcommands.  The "upload" subcommand uploads the signatures created with the
+private master key to the exchange.  It handles the output of all subcommands
+(except "download").  The "download" and "upload" commands must naturally be
+run "online" and do not require access to the offline key.
+
+All other subcommands are intended to be run "offline". However, especially
+when testing, it is of course possible to run the commands online as well.
+Generally, subcommands read inputs (beyond command-line arguments)
+from {\tt stdin}. However, they may also consume outputs of previous
+subcommands.  The outputs of multiple commands is automatically combined,
+and if not consumed the final output is printed to {\tt stdout}.
+
+
+The general options to for **taler-exchange-offline** are:
+
+**-c** *FILENAME* \| **––config=**\ ‌\ *FILENAME*
+   Use the configuration and other resources for the merchant to operate
+   from FILENAME.
+
+**-h** \| **––help**
+   Print short help on options.
+
+**-L** *LOGLEVEL* \| **––loglevel=**\ ‌\ *LOGLEVEL*
+   Specifies the log level to use. Accepted values are: DEBUG, INFO,
+   WARNING, ERROR.
+
+**-o** *FILE* \| **––output=**\ ‌\ *FILE*
+   Where to write a denomination key signing request file to be given to
+   the auditor.
+
+**-v** \| **––version**
+   Print version information.
+
+
+Configuration
+=============
+
+The exchange validates all operations by checking the signatures against the
+master public key that must be provided in the exchange configuration. To
+obtain the master public key, use:
+
+$ MASTER_PRIV_FILE=`taler-config -f -c $CONF -s EXCHANGE -o MASTER_PRIV_FILE`
+$ gnunet-ecc -p $MASTER_PRIV_FILE
+
+Note that if the private key file does not yet exist, the above will fail.
+In this case, create the private key using:
+
+$ MASTER_PRIV_FILE=`taler-config -f -c $CONF -s EXCHANGE -o MASTER_PRIV_FILE`
+$ MASTER_PRIV_DIR=`dirname $MASTER_PRIV_FILE`
+$ mkdir -p $MASTER_PRIV_DIR
+$ gnunet-ecc -g1 $MASTER_PRIV_FILE
+
+
+Relevant configuration options for **taler-exchange-offline** are:
+
+* [exchange/BASE_URL] --- how to reach the exchange (for download/upload)
+* [exchange-offline/MASTER_PRIV_FILE] --- where to store the private keys
+* [exchange-offline/SECM_TOFU_FILE] --- where to store TOFU data
+
+
+
+Subcommands
+===========
+
+download
+--------
+
+This command must be run online. It downloads future signing and denomination
+keys with the associated meta data from the exchange and outputs the resulting
+JSON (for consumption by subsequent commands, or to stdout).
+
+
+show
+----
+
+This command outputs information about future signing and denomination keys for
+manual checking against the business-approved fee structure, lifetimes and
+other parameters.
+
+It consumes the output of the "download" subcommand, either from "stdin" or
+directly.
+
+Its output always goes to "stdout" for human consumption (not in JSON).  It
+is usually a bad idea (but possible) to combine "show" with other commands,
+except maybe for testing.
+
+
+sign
+----
+
+This command signs information about future signing and denomination keys.
+
+It consumes the output of the "download" subcommand, either from "stdin" or
+directly.
+
+It outputs the signatures over *all* denomination and signing keys
+present in the input, in a format suitable for the "upload" subcommand.
+
+
+revoke-denomination
+-------------------
+
+This command signs a revocation message for a denomination key.
+
+The hash of the denomination public key must be given in the usual
+base32-encoding as the first and only argument to the subcommand.
+
+It outputs the signature affirming the revocation of the denomination key,
+in a format suitable for the "upload" subcommand.
+
+
+revoke-signkey
+--------------
+
+This command signs a revocation message for an exchange online signing key.
+
+The online signing public key must be given in the usual
+base32-encoding as the first and only argument to the subcommand.
+
+It outputs the signature affirming the revocation of the online signing key,
+in a format suitable for the "upload" subcommand.
+
+
+
+enable-auditor
+--------------
+
+Informs an exchange that an auditor is to be activated. Afterwards, the
+exchange will accept inputs from that auditor's **taler-auditor-offline**
+tool.  Note that the auditor also must add the exchange to the list of
+exchanges that it audits via **taler-auditor-exchange**. Furthermore, the
+exchange's database will need to be provided to the auditor.  This subcommand
+only informs the exchange about the auditor, but does not perform those
+additional mandatory steps for a working auditor.
+
+The auditor's public key must be given in the usual base32-encoding as the
+first argument.
+
+The auditor's REST API base URL must be given as the second argument. The tool
+performs a minimal sanity check, namely that the URL begins with "http"
+(this also allows "https"), but as it runs offline does not perform any further
+validation!
+
+The third argument must be a human-readable name for the auditor. This may
+be shown to users and should identify the auditor's business entity.  If
+the name includes spaces, the argument should be quoted.
+
+The subcommand takes no inputs from stdin or other subcommands.
+
+It outputs the signature affirming the addition of the auditor,
+in a format suitable for the "upload" subcommand.
+
+
+disable-auditor
+---------------
+
+Informs an exchange that an auditor is to be deactivated. Afterwards, the
+exchange will refuse inputs from that auditor's **taler-auditor-offline**
+tool.
+
+The auditor's public key must be given in the usual base32-encoding as the
+first argument.
+
+The subcommand takes no inputs from stdin or other subcommands.
+
+It outputs the signature affirming the removal of the auditor,
+in a format suitable for the "upload" subcommand.
+
+
+enable-account
+--------------
+
+Informs an exchange that it should advertise a bank account as belonging to
+the exchange on its ``/wire`` endpoint.  Note that this does *not* ensure that
+the exchange will use this bank account for incoming or outgoing wire
+transfers! For this, the **taler-exchange-transfer** and
+**taler-exchange-wirewatch** tools must be configured.  Furthermore, the bank
+account information advertised could theoretically differ from that which
+these tool actually use, for example if the public bank account is only a
+front for the actual internal business acounts.
+
+The payto:// URI (RFC 8905) of the exchange's bank account must be given
+as the first argument to the subcommand.
+
+The subcommand takes no inputs from stdin or other subcommands.
+
+It outputs the signature affirming the addition of the wire account,
+in a format suitable for the "upload" subcommand.
+
+
+disable-account
+---------------
+
+Informs an exchange that it should stop advertising a bank account as
+belonging to the exchange on its ``/wire`` endpoint.
+
+The payto:// URI (RFC 8905) of the exchange's (former) bank account must be
+given as the first argument to the subcommand.
+
+The subcommand takes no inputs from stdin or other subcommands.
+
+It outputs the signature affirming the deletion of the wire account, in a
+format suitable for the "upload" subcommand.
+
+
+wire-fee
+--------
+
+This subcommand informs an exchange about the desired wire fee (and closing fee)
+structure for particular wire method and a calendar year (!).  The tool does not
+permit changing wire fees during a calendar year. Also, once the wire fee has been
+set for a calendar year, it cannot be changed.
+
+The subcommand takes the year, wire-method (see RFC 8905, examples include
+``x-taler-bank`` or ``iban``), wire fee and closing fee as arguments.
+Instead of a year, the string ``now`` can be given for the current year
+(this is mostly useful for test cases).  The wire-method should follow the
+GANA registry as given in RFC 8905.  The fees must be given in the usual
+Taler format of ``CURRENCY:NUMBER.FRACTION``.
+
+The subcommand takes no inputs from stdin or other subcommands.
+
+It outputs the signature affirming the wire fees, in a format suitable for the
+"upload" subcommand.
+
+
+upload
+------
+
+This subcommand uploads outputs from other commands (except "download" and "show")
+to the exchange.  Note that it is possible that some uploads succeed, while others
+fail, as the operation is not atomic.
+
+The subcommand takes no arguments and has no output.
+
+
+help
+----
+
+This subcommand shows a summary of all available subcommands with the
+required arguments.
+
+
+
+Examples
+========
+
+Download future public keys from an exchange (online)
+-----------------------------------------------------
+
+$ taler-exchange-offline download > keys.json
+
+Show information about future public keys (offline or online)
+-------------------------------------------------------------
+
+$ taler-exchange-offline show < keys.json
+
+Sign future public keys (offline)
+---------------------------------
+
+$ taler-exchange-offline sign < keys.json > sigs.json
+
+Upload signatures about future public keys (online)
+---------------------------------------------------
+
+$ taler-exchange-offline upload < sigs.json
+
+Download, sign and upload, all in one (online)
+----------------------------------------------
+
+Note that doing this is only recommended in non-production deployments.
+
+$ taler-exchange-offline download sign upload
+
+
+Create signature to enable bank account (offline)
+-------------------------------------------------
+
+$ taler-exchange-offline enable-account payto://iban/DE24242 > account.json
+
+Upload bank account signature (online)
+--------------------------------------
+
+$ taler-exchange-offline upload < account.json
+
+
+Combine signing keys and enabling bank account (offline)
+--------------------------------------------------------
+
+$ taler-exchange-offline sign enable-account payto://iban/DE24242 < keys.json > combo.json
+
+Upload various signatures (online)
+----------------------------------
+
+$ taler-exchange-offline upload < combo.json
+
+Create multiple revocation messages in one pass (offline)
+---------------------------------------------------------
+
+$ taler-exchange-offline revoke-denomination $DKH1 revoke-denomination $DKH2 > revoke.json
+$ taler-exchange-offline revoke-signkey $SK1 revoke-signkey $SK2 > revoke.json
+$ taler-exchange-offline revoke-signkey $SK revoke-denomkey $DKH > mix.json
+
+The outputs ("revoke.json", "mix.json") must be uploaded using the "upload"
+command to the exchange to actually revoke the keys.
+
+
+
+Security considerations
+=======================
+
+The **taler-exchange-offline** tool assumes that it is run on a high-security
+system with *monotonic time*. The time does not have to precisely match that
+of the exchange, but it must be monotonic across tool invocations. The clock
+of the offline system is used in the enable/disable signatures to communicate
+an order of the events to the exchange.  This prevents someone from replaying
+an older "enable" (or "disable") message after a more recent "disable" (or
+"enable") message has been provided to the exchange.  Thus, there is no need
+to keep the actual files exchanged with the offline tool secret.
+
+The **taler-exchange-offline** tool tries to make sure that the online signing
+keys of the the exchange are always created by the same two security modules.
+The goal here is to prevent an attacker who compromised **taler-exchange-httpd**
+but *not* the security modules from providing attacker-controlled keys to the
+offline signing process.
+
+For this, the **taler-exchange-offline** signing subcommand always
+automatically learns the security module's public signing key and *trusts it
+on first use* (TOFU), but stores it to disk (see the ``SECM_TOFU_FILE`` option
+in the ``[exchange-offline]`` section of the configuration).  If the keys
+change subsequently, the tool will refuse to sign.
+
+
+
+See Also
+========
+
+taler-exchange-httpd(1), taler-auditor-offline(1), taler-auditor-exchange(1), taler.conf(5).
+
+Bugs
+====
+
+Report bugs by using https://bugs.taler.net/ or by sending electronic
+mail to <taler@gnu.org>.