update docu to reflect removal of ECDSA in favor of EdDSA

1 files changed, 12 insertions, 24 deletions

diff --git a/api-mint.rst b/api-mint.rst
index de04c71..580128a 100644
--- a/api-mint.rst
+++ b/api-mint.rst
@@ -26,18 +26,18 @@ This section describes how certain types of values are represented throughout th
 
   .. _public\ key:
 
-  * **Public key**: ECDSA, EdDSA and ECDHE public keys are always points on Curve25519 and represented using the Ed25519 standard compact format (256 bits), converted to Crockford Base32_.
+  * **Public key**: EdDSA and ECDHE public keys are always points on Curve25519 and represented using the Ed25519 standard compact format (256 bits), converted to Crockford Base32_.
 
   .. _Signature:
 
-  * **Signatures**: EdDSA and ECDSA signatures are be transmitted in two forms in the protocol.  As 64-byte base32_ binary-encoded objects with just the R and S values (base32_ binary-only), or as JSON objects with following fields (replace `eddsa` with `ecdsa` for ECDSA signatures):
+  * **Signatures**: EdDSA signatures are be transmitted in two forms in the protocol.  As 64-byte base32_ binary-encoded objects with just the R and S values (base32_ binary-only), or as JSON objects with following fields:
 
     * `purpose`: a unique number to state the context in which the signature is to be used in
     * `size`: the number of bytes that were hashed (using SHA-512) to create the signature; note that signatures are always done over a packed, binary representation of the data and not the JSON representations.
     * `eddsa_sig`: 64-byte base32_ binary encoding of the R and S values
     * `eddsa_val`: base32_ binary encoding of the full signed data (including again `purpose` and `size`)
 
-    RSA signatures are always simply base32_ encoded. The specific signature scheme in use (blind signature, ECDSA, EdDSA) depends on the context.
+    RSA signatures are always simply base32_ encoded. The specific signature scheme in use (blind signature, EdDSA) depends on the context.
 
   .. _Amount:
 
@@ -237,14 +237,14 @@ Deposit operations are requested by a merchant during a transaction. For the dep
   :<json object `wire`: the merchant's account details. This must be a JSON object whose format must correspond to one of the supported wire transfer formats of the mint.  See :ref:`wireformats`
   :<json base32 H_wire: SHA-512 hash of the merchant's payment details from `wire` (yes, strictly speaking redundant, but useful to detect inconsistencies)
   :<json base32 H_contract: SHA-512 hash of the contact of the merchant with the customer (further details are never disclosed to the mint)
-  :<json base32 coin_pub: coin's public key (ECDHE and ECDSA)
+  :<json base32 coin_pub: coin's public key (ECDHE and EdDSA)
   :<json base32 denom_pub: denomination (RSA) key with which the coin is signed
   :<json base32 ub_sig: mint's unblinded RSA signature_ of the coin
   :<json date timestamp: timestamp when the contract was finalized, must match approximately the current time of the mint
   :<json int transaction_id: 64-bit transaction id for the transaction between merchant and customer
   :<json base32 merchant_pub: the EdDSA public key of the merchant (used to identify the merchant for refund requests)
   :<json date refund_deadline: date until which the merchant can issue a refund to the customer via the mint (can be zero if refunds are not allowed)
-  :<json base32 coin_sig: the ECDSA signature_ (binary-only) made with purpose `TALER_SIGNATURE_WALLET_COIN_DEPOSIT` made by the customer with the coin's private key.
+  :<json base32 coin_sig: the EdDSA signature_ (binary-only) made with purpose `TALER_SIGNATURE_WALLET_COIN_DEPOSIT` made by the customer with the coin's private key.
 
   The deposit operation succeeds if the coin is valid for making a deposit and has enough residual value that has not already been deposited, refreshed or locked.
 
@@ -304,7 +304,7 @@ However, the new coins are linkable from the private keys of all old coins using
   :<json array coin_evs: For each of the `n` new coins, `kappa` coin blanks (2D array)
   :<json array transfer_pubs: For each of the `m` old coins, `kappa` transfer public keys (2D-array of ephemeral ECDHE keys)
   :<json array secret_encs: For each of the `m` old coins, `kappa` link encryptions with an ECDHE-encrypted SHA-512 hash code.  The ECDHE encryption is done using the private key of the respective old coin and the corresponding transfer public key.  Note that the SHA-512 hash code must be the same across all coins, but different across all of the `kappa` dimensions.  Given the private key of a single old coin, it is thus possible to decrypt the respective `secret_encs` and obtain the SHA-512 hash that was used to symetrically encrypt the `link_encs` of all of the new coins.
-  :<json array link_encs: For each of the `n` new coins, `kappa` (symmetric) encryptions of the ECDSA/ECDHE-private key of the new coins and the corresponding blinding factor, encrypted using the corresponding SHA-512 hash that is encrypted in `secret_encs`.
+  :<json array link_encs: For each of the `n` new coins, `kappa` (symmetric) encryptions of the EdDSA/ECDHE-private key of the new coins and the corresponding blinding factor, encrypted using the corresponding SHA-512 hash that is encrypted in `secret_encs`.
 
   For details about the HKDF used to derive the symmetric encryption keys from ECDHE and the symmetric encryption (AES+Twofish) used, please refer to the implementation in `libtalerutil`. The `melt_coins` field is a list of JSON objects with the following fields:
 
@@ -621,19 +621,7 @@ binary-compatible with the implementation of the mint.
   :resheader Content-Type: application/json
   :>json base32 ecdh_hash: ECDH result from the two keys
 
-.. http:POST:: /test/ecdsa
-
-  Test ECDSA.  We do not (yet) test that the client correctly implemented RFC 6979.
-
-  :reqheader Content-Type: application/json
-  :<json base32 ecdsa_pub: ECDSA public key
-  :<json base32 ecdsa_sig: ECDSA signature using purpose TALER_SIGNATURE_CLIENT_TEST_ECDSA
-  :status 200: the signature was valid
-  :resheader Content-Type: application/json
-  :>json base32 ecdsa_pub: Another ECDSA public key
-  :>json base32 ecdsa_sig: ECDSA signature using purpose TALER_SIGNATURE_MINT_TEST_ECDSA
-
-.. http:POST:: /test/ecdsa
+.. http:POST:: /test/eddsa
 
   Test EdDSA.
 
@@ -739,7 +727,7 @@ All elliptic curve operations are on Curve25519.  Public and private keys are th
    };
 
    struct TALER_TransferPublicKeyP {
-     uint8_t ecdsa_pub[32];
+     uint8_t ecdhe_pub[32];
    };
 
    struct TALER_TransferPrivateKeyP {
@@ -771,17 +759,17 @@ All elliptic curve operations are on Curve25519.  Public and private keys are th
    };
 
    union TALER_CoinSpendPublicKeyP {
-     uint8_t ecdsa_pub[32];
+     uint8_t eddsa_pub[32];
      uint8_t ecdhe_pub[32];
    };
 
    union TALER_CoinSpendPrivateKeyP {
-     uint8_t ecdsa_priv[32];
+     uint8_t eddsa_priv[32];
      uint8_t ecdhe_priv[32];
    };
 
    struct TALER_CoinSpendSignatureP {
-     uint8_t ecdsa_signature[64];
+     uint8_t eddsa_signature[64];
    };
 
    struct TALER_TransferSecretP {
@@ -800,7 +788,7 @@ All elliptic curve operations are on Curve25519.  Public and private keys are th
 Signatures
 ------------------------
 
-EdDSA and ECDSA signatures are always made over (the hash of) a block of the same generic format, the `struct SignedData` given below.  In our notation, the type of a field can depend on the value of another field. For the following message, the length of the `payload` array must match the value of the `size` field:
+EdDSA signatures are always made over (the hash of) a block of the same generic format, the `struct SignedData` given below.  In our notation, the type of a field can depend on the value of another field. For the following message, the length of the `payload` array must match the value of the `size` field:
 
 .. sourcecode:: c