summaryrefslogtreecommitdiff
path: root/design-documents/010-exchange-helpers.rst
diff options
context:
space:
mode:
Diffstat (limited to 'design-documents/010-exchange-helpers.rst')
-rw-r--r--design-documents/010-exchange-helpers.rst10
1 files changed, 5 insertions, 5 deletions
diff --git a/design-documents/010-exchange-helpers.rst b/design-documents/010-exchange-helpers.rst
index e67fca4e..c63921b6 100644
--- a/design-documents/010-exchange-helpers.rst
+++ b/design-documents/010-exchange-helpers.rst
@@ -1,5 +1,5 @@
-Design Doc 010: Exchange crypto helper design
-#############################################
+DD 10: Exchange crypto helper design
+####################################
Summary
=======
@@ -13,7 +13,7 @@ Motivation
We want to provide an additional layer of protection for the private online
signing keys used by the exchange. The exchange is network-facing, includes an
-HTTP server, Postgres interaction, JSON parser and quite a bit of other logic
+HTTP server, PostgreSQL interaction, JSON parser and quite a bit of other logic
which may all be theoretically vulnerable to remote exploitation. Thus, it
would be good from a security perspective to protect the private online
signing keys via an additional layer of protection.
@@ -89,7 +89,7 @@ Exchange design considerations:
exchange. This simplifies the exchange, and we already needed the
exchange operator to start four processes to operate an exchange.
So this number simply increases to six (not even counting the
- Postgres database and a reverse HTTP proxy for TLS termination).
+ PostgreSQL database and a reverse HTTP proxy for TLS termination).
* Each exchange thread will create its own connection to the helpers, and will
block while waiting on the helper to create a signature. This keeps the
exchange logic simple and similar to the existing in-line signing calls.
@@ -108,7 +108,7 @@ New exchange endpoints:
sign based on that file, and then upload the resulting signature back to
the exchange. For this, master signatures will be POSTed to
the exchange to the ``/keys`` endpoint.
- The exchange will keep those signatures in the Postgres database.
+ The exchange will keep those signatures in the PostgreSQL database.
* A new endpoint (``/auditors``) will also allow adding/removing auditors
(POST, DELETE) using requests signed with the offline master private key.
Once an auditor has been added, the respective auditor signatures on exchange