lsd0009

draft-guetschow-taler-protocol.xml (37834B)

---

 <?xml version="1.0" encoding="UTF-8"?>
   <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
   <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.17 (Ruby 3.1.2) -->
 
 
 <!DOCTYPE rfc  [
   <!ENTITY nbsp    "&#160;">
   <!ENTITY zwsp   "&#8203;">
   <!ENTITY nbhy   "&#8209;">
   <!ENTITY wj     "&#8288;">
 
 ]>
 
 
 <rfc ipr="trust200902" docName="draft-guetschow-taler-protocol" category="info" submissionType="independent" tocInclude="true" sortRefs="true" symRefs="true">
   <front>
     <title>The GNU Taler Protocol</title>
 
     <author initials="M." surname="Gütschow" fullname="Mikolai Gütschow">
       <organization abbrev="TU Dresden">TUD Dresden University of Technology</organization>
       <address>
         <postal>
           <street>Helmholtzstr. 10</street>
           <city>Dresden</city>
           <code>D-01069</code>
           <country>Germany</country>
         </postal>
         <email>mikolai.guetschow@tu-dresden.de</email>
       </address>
     </author>
 
     <date year="2025" month="August" day="12"/>
 
     
     <workgroup>independent</workgroup>
     <keyword>taler</keyword> <keyword>cryptography</keyword> <keyword>ecash</keyword> <keyword>payments</keyword>
 
     <abstract>
 
 
 <?line 43?>
 
 <t>[ TBW ]</t>
 
 
 
     </abstract>
 
 
 
   </front>
 
   <middle>
 
 
 <?line 47?>
 
 <section anchor="introduction"><name>Introduction</name>
 
 <t>[ TBW ]</t>
 
 <t>Beware that this document is still work-in-progress and may contain errors.
 Use at your own risk!</t>
 
 </section>
 <section anchor="notation"><name>Notation</name>
 
 <t><list style="symbols">
   <t><spanx style="verb">"abc"</spanx> denotes the literal string <spanx style="verb">abc</spanx> encoded as ASCII <xref target="RFC20"></xref></t>
   <t><spanx style="verb">a | b</spanx> denotes the concatenation of a with b</t>
   <t><spanx style="verb">len(a)</spanx> denotes the length in bytes of the byte string a</t>
   <t><spanx style="verb">padZero(y, a)</spanx> denotes the byte string a, zero-padded to the length of y bytes</t>
   <t><spanx style="verb">bits(x)</spanx>/<spanx style="verb">bytes(x)</spanx> denotes the minimal number of bits/bytes necessary to represent the multiple precision integer x</t>
   <t><spanx style="verb">uint(y, x)</spanx> denotes the <spanx style="verb">y</spanx> least significant bits of the integer <spanx style="verb">x</spanx> encoded in network byte order (big endian)</t>
   <t><spanx style="verb">uint16(x)</spanx>/<spanx style="verb">uint32(x)</spanx>/<spanx style="verb">uint64(x)</spanx>/<spanx style="verb">uint256(x)</spanx>/<spanx style="verb">uint512(x)</spanx> is equivalent to <spanx style="verb">uint(16, x)</spanx>/<spanx style="verb">uint(32, x)</spanx>/<spanx style="verb">uint(64, x)</spanx>/<spanx style="verb">uint(256, x)</spanx>/<spanx style="verb">uint(512, x)</spanx>, respectively</t>
   <t><spanx style="verb">random(y)</spanx> denotes a randomly generated sequence of y bits</t>
   <t><spanx style="verb">a * b (mod N)</spanx> / <spanx style="verb">a ** b (mod N)</spanx> denotes the multiplication / exponentiation of multiple precision integers a and b, modulo N</t>
 </list></t>
 
 </section>
 <section anchor="cryptographic-primitives"><name>Cryptographic Primitives</name>
 
 <section anchor="cryptographic-hash-functions"><name>Cryptographic Hash Functions</name>
 
 <section anchor="sha256"><name>SHA-256</name>
 
 <figure><artwork><![CDATA[
 SHA-256(msg) -> hash
 
 Input:
     msg     input message of length L < 2^61 octets
 
 Output:
     hash    message digest of fixed length HashLen = 32 octets
 ]]></artwork></figure>
 
 <t><spanx style="verb">hash</spanx> is the output of SHA-256 as per Sections 4.1, 5.1, 6.1, and 6.2 of <xref target="RFC6234"></xref>.</t>
 
 </section>
 <section anchor="sha512"><name>SHA-512</name>
 
 <figure><artwork><![CDATA[
 SHA-512(msg) -> hash
 
 Input:
     msg     input message of length L < 2^125 octets
 
 Output:
     hash    message digest of fixed length HashLen = 64 octets
 ]]></artwork></figure>
 
 <t><spanx style="verb">hash</spanx> is the output of SHA-512 as per Sections 4.2, 5.2, 6.3, and 6.4 of <xref target="RFC6234"></xref>.</t>
 
 </section>
 <section anchor="sha512-trunc"><name>SHA-512-256 (truncated SHA-512)</name>
 
 <figure><artwork><![CDATA[
 SHA-512-256(msg) -> hash
 
 Input:
     msg     input message of length L < 2^125 octets
 
 Output:
     hash    message digest of fixed length HashLen = 32 octets
 ]]></artwork></figure>
 
 <t>The output <spanx style="verb">hash</spanx> corresponds to the first 32 octets of the output of SHA-512 defined in <xref target="sha512"/>:</t>
 
 <figure><artwork><![CDATA[
 temp = SHA-512(msg)
 hash = temp[0:31]
 ]]></artwork></figure>
 
 <t>Note that this operation differs from SHA-512/256 as defined in <xref target="SHS"></xref> in the initial hash value.</t>
 
 </section>
 </section>
 <section anchor="message-authentication-codes"><name>Message Authentication Codes</name>
 
 <section anchor="hmac"><name>HMAC</name>
 
 <figure><artwork><![CDATA[
 HMAC-Hash(key, text) -> out
 
 Option:
     Hash    cryptographic hash function with output length HashLen
 
 Input:
     key     secret key of length at least HashLen
     text    input data of arbitary length
 
 Output:
     out     output of length HashLen
 ]]></artwork></figure>
 
 <t><spanx style="verb">out</spanx> is calculated as defined in <xref target="RFC2104"></xref>.</t>
 
 </section>
 </section>
 <section anchor="key-derivation-functions"><name>Key Derivation Functions</name>
 
 <section anchor="hkdf"><name>HKDF</name>
 
 <t>The Hashed Key Derivation Function (HKDF) used in Taler is an instantiation of <xref target="RFC5869"></xref>
 with two different hash functions for the Extract and Expand step as suggested in <xref target="HKDF"></xref>:
 <spanx style="verb">HKDF-Extract</spanx> uses <spanx style="verb">HMAC-SHA512</spanx>, while <spanx style="verb">HKDF-Expand</spanx> uses <spanx style="verb">HMAC-SHA256</spanx> (cf. <xref target="hmac"/>).</t>
 
 <figure><artwork><![CDATA[
 HKDF(salt, IKM, info, L) -> OKM
 
 Inputs:
     salt    optional salt value (a non-secret random value);
               if not provided, it is set to a string of 64 zeros.
     IKM     input keying material
     info    optional context and application specific information
               (can be a zero-length string)
     L       length of output keying material in octets
               (<= 255*32 = 8160)
 
 Output:
     OKM      output keying material (of L octets)
 ]]></artwork></figure>
 
 <t>The output OKM is calculated as follows:</t>
 
 <figure><artwork><![CDATA[
 PRK = HKDF-Extract(salt, IKM) with Hash = SHA-512 (HashLen = 64)
 OKM = HKDF-Expand(PRK, info, L) with Hash = SHA-256 (HashLen = 32)
 ]]></artwork></figure>
 
 </section>
 <section anchor="hkdf-mod"><name>HKDF-Mod</name>
 
 <t>Based on the HKDF defined in <xref target="hkdf"/>, this function returns an OKM that is smaller than a given multiple precision integer N.</t>
 
 <figure><artwork><![CDATA[
 HKDF-Mod(N, salt, IKM, info) -> OKM
 
 Inputs:
     N        multiple precision integer
     salt     optional salt value (a non-secret random value);
               if not provided, it is set to a string of 64 zeros.
     IKM      input keying material
     info     optional context and application specific information
               (can be a zero-length string)
 
 Output:
     OKM      output keying material (smaller than N)
 ]]></artwork></figure>
 
 <t>The final output <spanx style="verb">OKM</spanx> is determined deterministically based on a counter initialized at zero.</t>
 
 <figure><artwork><![CDATA[
 counter = 0
 do until OKM < N:
     x = HKDF(salt, IKM, info | uint16(counter), bytes(N))
     OKM = uint(bits(N), x)
     counter += 1
 ]]></artwork></figure>
 
 </section>
 </section>
 <section anchor="non-blind-signatures"><name>Non-Blind Signatures</name>
 
 <section anchor="ed25519"><name>Ed25519</name>
 
 </section>
 </section>
 <section anchor="blind-signatures"><name>Blind Signatures</name>
 
 <section anchor="rsa-fdh"><name>RSA-FDH</name>
 
 <section anchor="supporting-functions"><name>Supporting Functions</name>
 
 <figure><artwork><![CDATA[
 RSA-FDH(msg, pubkey) -> fdh
 
 Inputs:
     msg     message
     pubkey  RSA public key consisting of modulus N and public exponent e
 
 Output:
     fdh     full-domain hash of msg over pubkey.N
 ]]></artwork></figure>
 
 <t><spanx style="verb">fdh</spanx> is calculated based on HKDF-Mod from <xref target="hkdf-mod"/> as follows:</t>
 
 <figure><artwork><![CDATA[
 info = "RSA-FDA FTpsW!"
 salt = uint16(bytes(pubkey.N)) | uint16(bytes(pubkey.e))
      | pubkey.N | pubkey.e
 fdh = HKDF-Mod(pubkey.N, salt, msg, info)
 ]]></artwork></figure>
 
 <t>The resulting <spanx style="verb">fdh</spanx> can be used to test against a malicious RSA pubkey
 by verifying that the greatest common denominator (gcd) of <spanx style="verb">fdh</spanx> and <spanx style="verb">pubkey.N</spanx> is 1.</t>
 
 <figure><artwork><![CDATA[
 RSA-FDH-Derive(bks, pubkey) -> out
 
 Inputs:
     bks     blinding key secret of length L = 32 octets
     pubkey  RSA public key consisting of modulus N and public exponent e
 
 Output:
     out     full-domain hash of bks over pubkey.N
 ]]></artwork></figure>
 
 <t><spanx style="verb">out</spanx> is calculated based on HKDF-Mod from <xref target="hkdf-mod"/> as follows:</t>
 
 <figure><artwork><![CDATA[
 info = "Blinding KDF"
 salt = "Blinding KDF extractor HMAC key"
 fdh = HKDF-Mod(pubkey.N, salt, bks, info)
 ]]></artwork></figure>
 
 </section>
 <section anchor="blinding"><name>Blinding</name>
 
 <figure><artwork><![CDATA[
 RSA-FDH-Blind(msg, bks, pubkey) -> out
 
 Inputs:
     msg     message
     bks     blinding key secret of length L = 32 octets
     pubkey  RSA public key consisting of modulus N and public exponent e
 
 Output:
     out     message blinded for pubkey
 ]]></artwork></figure>
 
 <t><spanx style="verb">out</spanx> is calculated based on RSA-FDH from <xref target="rsa-fdh"/> as follows:</t>
 
 <figure><artwork><![CDATA[
 data = RSA-FDH(msg, pubkey)
 r = RSA-FDH-Derive(bks, pubkey)
 r_e = r ** pubkey.e (mod pubkey.N)
 out = r_e * data (mod pubkey.N)
 ]]></artwork></figure>
 
 </section>
 <section anchor="signing"><name>Signing</name>
 
 <figure><artwork><![CDATA[
 RSA-FDH-Sign(data, privkey) -> sig
 
 Inputs:
     data    data to be signed, an integer smaller than privkey.N
     privkey RSA private key consisting of modulus N and private exponent d
 
 Output:
     sig     signature on data by privkey
 ]]></artwork></figure>
 
 <t><spanx style="verb">sig</spanx> is calculated as follows:</t>
 
 <figure><artwork><![CDATA[
 sig = data ** privkey.d (mod privkey.N)
 ]]></artwork></figure>
 
 </section>
 <section anchor="unblinding"><name>Unblinding</name>
 
 <figure><artwork><![CDATA[
 RSA-FDH-Unblind(sig, bks, pubkey) -> out
 
 Inputs:
     sig     blind signature
     bks     blinding key secret of length L = 32 octets
     pubkey  RSA public key consisting of modulus N and public exponent e
 
 Output:
     out     unblinded signature
 ]]></artwork></figure>
 
 <t><spanx style="verb">out</spanx> is calculated as follows:</t>
 
 <figure><artwork><![CDATA[
 r = RSA-FDH-Derive(bks, pubkey)
 r_inv = inverse of r (mod pubkey.N)
 out = sig * r_inv (mod pubkey.N)
 ]]></artwork></figure>
 
 </section>
 <section anchor="verifying"><name>Verifying</name>
 
 <figure><artwork><![CDATA[
 RSA-FDH-Verify(msg, sig, pubkey) -> out
 
 Inputs:
     msg     message
     sig     signature of pubkey over msg
     pubkey  RSA public key consisting of modulus N and public exponent e
 
 Output:
     out     true, if sig is a valid signature
 ]]></artwork></figure>
 
 <t><spanx style="verb">out</spanx> is calculated based on RSA-FDH from <xref target="rsa-fdh"/> as follows:</t>
 
 <figure><artwork><![CDATA[
 data = RSA-FDH(msg, pubkey)
 exp = sig ** pubkey.e (mod pubkey.N)
 out = (data == exp)
 ]]></artwork></figure>
 
 </section>
 </section>
 <section anchor="clause-schnorr"><name>Clause-Schnorr</name>
 
 </section>
 </section>
 </section>
 <section anchor="the-taler-crypto-protocol"><name>The Taler Crypto Protocol</name>
 
 <section anchor="datatypes"><name>Datatypes</name>
 
 <section anchor="amount"><name>Amount</name>
 
 <t>Amounts are represented in Taler as positive fixed-point values
 consisting of <spanx style="verb">value</spanx> as the non-negative integer part of the base currency,
 the <spanx style="verb">fraction</spanx> given in units of one hundred millionth (1e-8) of the base currency,
 and <spanx style="verb">currency</spanx> as the 3-11 ASCII characters identifying the currency.</t>
 
 <t>Whenever used in the protocol, the binary representation of an <spanx style="verb">amount</spanx> is
 <spanx style="verb">uint64(amount.value) | uint32(amount.fraction) | padZero(12, amount.currency)</spanx>.</t>
 
 </section>
 <section anchor="timestamps"><name>Timestamps</name>
 
 <t>Absolute timestamps are represented as <spanx style="verb">uint64(x)</spanx> where <spanx style="verb">x</spanx> corresponds to
 the microseconds since <spanx style="verb">1970-01-01 00:00 CEST</spanx> (the UNIX epoch).
 The special value <spanx style="verb">0xFFFFFFFFFFFFFFFF</spanx> represents "never".
 <!--
 // todo: check if needed and correct
 Relative timestamps are represented as `uint64(x)` where `x` is given in microseconds.
 The special value `0xFFFFFFFFFFFFFFFF` represents "forever".
 --></t>
 
 </section>
 <section anchor="signatures"><name>Signatures</name>
 
 <t>All messages to be signed in Taler start with a header containing their size and
 a fixed signing context (purpose) as registered by GANA in the
 <eref target="https://gana.gnunet.org/gnunet-signatures/gnunet_signatures.html">GNUnet Signature Purposes</eref>
 registry. All Taler-related purposes start at 1000 and can be found in the
 <eref target="https://git.taler.net/gana.git/tree/gnunet-signatures/registry.rec#n221">registry sources</eref>.</t>
 
 <figure><artwork><![CDATA[
 Sign-Msg(purpose, msg) -> out
 
 Inputs:
     purpose signature purpose as registered at GANA
     msg     message content (excl. header) to be signed
 
 Output:
     out     complete message (incl. header) to be signed
 ]]></artwork></figure>
 
 <t><spanx style="verb">out</spanx> is formed as follows:</t>
 
 <figure><artwork><![CDATA[
 out = uint32(len(msg)) | uint32(purpose) | msg
 ]]></artwork></figure>
 
 <t>// todo: explain persist, check, knows, sum</t>
 
 </section>
 </section>
 <section anchor="withdrawal"><name>Withdrawal</name>
 
 <t>The wallet generates <spanx style="verb">n &gt; 0</spanx> coins (<spanx style="verb">coin[i]</spanx>) and requests <spanx style="verb">n</spanx> signatures (<spanx style="verb">blind_sig[i]</spanx>) from the exchange,
 attributing value to the coins according to <spanx style="verb">n</spanx> chosen denominations (<spanx style="verb">denom[i]</spanx>).
 The total value and withdrawal fee (defined by the exchange per denomination)
 must be smaller or equal to the amount stored in the single reserve used for withdrawal.</t>
 
 <figure><artwork><![CDATA[
             wallet                                  exchange
 knows denom[i].pub                      knows denom[i].priv
                |                                        |
 +----------------------------+                          |
 | (1) reserve key generation |                          |
 +----------------------------+                          |
                |                                        |
                |----------- (bank transfer) ----------->|
                | (subject: reserve.pub, amount: value)  |
                |                                        |
                |                      +------------------------------+
                |                      | persist (reserve.pub, value) |
                |                      +------------------------------+
                |                                        |
 +----------------------------------+                    |
 | (2) coin generation and blinding |                    |
 +----------------------------------+                    |
                |                                        |
                |-------------- /withdraw -------------->|
                |     (reserve.pub, coin[i].h_denom,     |
                |           blind_coin[i], sig0)         |
                |                                        |
                |                      +-------------------------------+
                |                      | (3) coin issuance and signing |
                |                      +-------------------------------+
                |                                        |
                |<----------- blind_sig[i] --------------|
                |                                        |
 +---------------------+                                 |
 | (4) coin unblinding |                                 |
 +---------------------+                                 |
 ]]></artwork></figure>
 
 <t>where (for RSA, without age-restriction)</t>
 
 <figure><artwork><![CDATA[
 (1) reserve key generation (wallet)
 
 reserve = EdDSA-Keygen()
 persist (reserve, value)
 ]]></artwork></figure>
 
 <t>The wallet derives coins and blinding secrets using a HKDF from a master secret per withdrawal and an integer index.
 This is strictly speaking an implementation detail since the master secret is never revealed to any other party,
 and might be chosen to be implemented differently.</t>
 
 <figure><artwork><![CDATA[
 (2) coin generation and blinding (wallet)
 
 master_secret = random(256)
 persist master_secret
 coin_seed[i] = HKDF(uint32(i), master_secret, "taler-withdrawal-coin-derivation", 64)
 blind_secret[i] = coin_seed[i][32:]
 coin[i].priv = coin_seed[i][:32]
 coin[i].pub = EdDSA-GetPub(coin[i].priv)
 coin[i].h_denom = SHA-512(uint32(0) | uint32(1) | denom[i].pub)
 blind_coin[i] = RSA-FDH-Blind(SHA-512(coin[i].pub), blind_secret[i], denom[i].pub)
 msg0 = Sign-Msg(WALLET_RESERVE_WITHDRAW,
     ( sum(denom[i].value) | sum(denom[i].fee_withdraw)
     | SHA-512( SHA-512(denom[i].pub) | uint32(0x1) | blind_coin[i] )
     | uint256(0x0) | uint32(0x0) | uint32(0x0) ))
 sig0 = EdDSA-Sign(reserve.priv, msg0)
 ]]></artwork></figure>
 
 <figure><artwork><![CDATA[
 (3) coin issuance and signing (exchange)
 
 denom[i] = Denom-Lookup(coin[i].h_denom)
 check denom[i].pub known and not withdrawal-expired
 check EdDSA-Verify(reserve.pub, msg, sig)
 check reserve KYC status ok or not needed
 check reserve.balance >= sum(denom[i].value + denom[i].fee_withdraw)
 reserve.balance -= sum(denom[i].value + denom[i].fee_withdraw)
 blind_sig[i] = RSA-FDH-Sign(blind_coin[i], denom[i].priv)
 persist withdrawal
 ]]></artwork></figure>
 
 <figure><artwork><![CDATA[
 (4) coin unblinding (wallet)
 
 coin[i].sig = RSA-FDH-Unblind(blind_sig[i], blind_secret[i], denom[i].pub)
 check RSA-FDH-Verify(SHA-512(coin[i].pub), coin[i].sig, denom[i].pub)
 persist (coin[i], blind_secret[i])
 ]]></artwork></figure>
 
 </section>
 <section anchor="payment"><name>Payment</name>
 
 <figure><artwork><![CDATA[
             wallet                                  merchant
 knows merchant.pub                      knows merchant.priv
 knows valid coin[i]                     knows exchange, payto
                |                                        |
                |                      +----------------------+
                |                      | (1) order generation |
                |                      +----------------------+
                |                                        |
                |<-------- (order.{id,token?}) ----------|
                |                                        |
 +----------------------+                                |
 | (2) nonce generation |                                |
 +----------------------+                                |
                |                                        |
                |------- /orders/{order.id}/claim ------>|
                |          (nonce.pub, token?)           |
                |                                        |
                |                      +-------------------------+
                |                      | (3) contract generation |
                |                      +-------------------------+
                |                                        |
                |<----------- contract, sig -------------|
                |                                        |
 +-------------------------+                             |
 | (4) payment preparation |                             |
 +-------------------------+                             |
                |                                        |
                |------- /orders/{order.id}/pay -------->|
                |             (deposit[i])               |
                |                                        |
                |                      +-------------------+
                |                      | (5) deposit check |
                |                      +-------------------+
                |                                        |
                |<---------------- sig ------------------|
                |                                        |
 +--------------------------+                            |
 | (6) payment verification |                            |
 +--------------------------+                            |
 ]]></artwork></figure>
 
 <t>where (without age restriction, policy and wallet data hash)</t>
 
 <figure><artwork><![CDATA[
 (1) order generation (merchant)
 
 wire_salt = random(128)
 persist order = (id, price, info, token?, wire_salt)
 ]]></artwork></figure>
 
 <figure><artwork><![CDATA[
 (2) nonce generation (wallet)
 
 nonce = EdDSA-Keygen()
 persist nonce.priv
 ]]></artwork></figure>
 
 <t>Note that the private key of <spanx style="verb">nonce</spanx> is currently not used anywhere in the protocol.
 However, it could be used in the future to prove ownership of an order transaction,
 enabling use-cases such as "unclaiming" or transferring an order to another person,
 or proving the payment without resorting to the individual coins.</t>
 
 <figure><artwork><![CDATA[
 (3) contract generation (merchant)
 
 h_wire = HKDF(wire_salt, payto, "merchant-wire-signature", 64)
 determine timestamp, refund_deadline, wire_deadline
 contract = (order.{id,price,info,token?}, exchange, h_wire, timestamp, refund_deadline, wire_deadline)
 check contract.order.token = token?
 contract.nonce = nonce.pub
 persist contract
 h_contract = SHA-512(canonicalJSON(contract))
 msg = Sign-Msg(MERCHANT_CONTRACT, h_contract)
 sig = EdDSA-Sign(merchant.priv, msg)
 ]]></artwork></figure>
 
 <figure><artwork><![CDATA[
 (4) payment preparation (wallet)
 
 check EdDSA-Verify(merchant.pub, msg, sig)
 check contract.nonce = nonce
 TODO: double-check extra hash check?
 deposit = CoinSelection(contract.{exchange,price}) TODO: include MarkDirty here
 msg[i] = Sign-Msg(WALLET_COIN_DEPOSIT,
     ( h_contract | uint256(0x0)
     | uint512(0x0) | contract.h_wire | coin[i].h_denom
     | contract.timestamp | contract.refund_deadline
     | deposit[i] + denom[i].fee_deposit
     | denom[i].fee_deposit | merchant.pub | uint512(0x0) ))
 sig[i] = EdDSA-Sign(coin[i].priv, msg[i])
 deposit[i] = (coin[i].{pub,sig,h_denom}, fraction[i], sig[i])
 persist (contract, sig[i], deposit[i])
 ]]></artwork></figure>
 
 <figure><artwork><![CDATA[
 (5) deposit check (merchant)
 
 check sum(deposit[i].fraction) == contract.price
 check Deposit(deposit)[i]
 msg = Sign-Msg(MERCHANT_PAYMENT_OK, h_contract)
 sig = EdDSA-Sign(merchant.priv, msg)
 ]]></artwork></figure>
 
 <figure><artwork><![CDATA[
 (6) payment verification
 
 check EdDSA-Verify(merchant.pub, msg, sig)
 ]]></artwork></figure>
 
 </section>
 <section anchor="deposit"><name>Deposit</name>
 
 <figure><artwork><![CDATA[
        merchant/wallet                              exchange
 knows exchange.pub                      knows exchange.priv
 knows merchant.pub                      knows *denom.pub
 knows payto, wire_salt, sig2, h_contract
 knows contract, *deposit from Payment
                |                                        |
                |----------- /batch-deposit ------------>|
                | (contract.{timestamp,wire_deadline,refund_deadline}
                |  h_contract, merchant.pub, sig2,       |
                |  payto, *deposit, wire_salt)           |
                |                                        |
                |                        *denom = Denom-Lookup(*deposit.coin.h_denom)
                |                        check *denom.pub known and not deposit-expired
                |                        contract.h_wire = HKDF(wire_salt, payto,
                |                                               "merchant-wire-signature", 64)
                |                        check *EdDSA-Verify(deposit.coin.pub, msg1, sig1)
                |                        check *RSA-FDH-Verify(SHA-512(deposit.coin.pub),
                |                                              deposit.coin.sig, denom.pub)
                |                        check not overspending
                |                        persist deposit-record, mark-spent
                |                        schedule bank transfer
                |                        exchange_timestamp = now()
                |                        sig3 = EdDSA-Sign(exchange.priv, msg3)
                |                                        |
                |<----- sig3, exchange_timestamp --------|
                |                                        |
 check EdDSA-Verify(exchange.pub, msg3, sig3)            |
 ]]></artwork></figure>
 
 <t>where <spanx style="verb">msg3</spanx> is formed as follows:</t>
 
 <figure><artwork><![CDATA[
 msg3 = Sign-Msg(EXCHANGE_CONFIRM_DEPOSIT,
     ( h_contract | contract.h_wire | uint512(0x0)
     | exchange_timestamp | contract.wire_deadline
     | contract.refund_deadline
     | sum(*deposit.fraction - *denom.fee_deposit)
     | SHA-512(*deposit.sig1) | merchant.pub ))
 ]]></artwork></figure>
 
 </section>
 </section>
 <section anchor="security-considerations"><name>Security Considerations</name>
 
 <t>[ TBD ]</t>
 
 </section>
 <section anchor="iana-considerations"><name>IANA Considerations</name>
 
 <t>None.</t>
 
 </section>
 
 
   </middle>
 
   <back>
 
 
     <references title='Normative References' anchor="sec-normative-references">
 
 
 
 <reference anchor="RFC20">
   <front>
     <title>ASCII format for network interchange</title>
     <author fullname="V.G. Cerf" initials="V.G." surname="Cerf"/>
     <date month="October" year="1969"/>
   </front>
   <seriesInfo name="STD" value="80"/>
   <seriesInfo name="RFC" value="20"/>
   <seriesInfo name="DOI" value="10.17487/RFC0020"/>
 </reference>
 
 <reference anchor="RFC2104">
   <front>
     <title>HMAC: Keyed-Hashing for Message Authentication</title>
     <author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/>
     <author fullname="M. Bellare" initials="M." surname="Bellare"/>
     <author fullname="R. Canetti" initials="R." surname="Canetti"/>
     <date month="February" year="1997"/>
     <abstract>
       <t>This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind</t>
     </abstract>
   </front>
   <seriesInfo name="RFC" value="2104"/>
   <seriesInfo name="DOI" value="10.17487/RFC2104"/>
 </reference>
 
 <reference anchor="RFC5869">
   <front>
     <title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)</title>
     <author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/>
     <author fullname="P. Eronen" initials="P." surname="Eronen"/>
     <date month="May" year="2010"/>
     <abstract>
       <t>This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
     </abstract>
   </front>
   <seriesInfo name="RFC" value="5869"/>
   <seriesInfo name="DOI" value="10.17487/RFC5869"/>
 </reference>
 
 <reference anchor="RFC6234">
   <front>
     <title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</title>
     <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
     <author fullname="T. Hansen" initials="T." surname="Hansen"/>
     <date month="May" year="2011"/>
     <abstract>
       <t>Federal Information Processing Standard, FIPS</t>
     </abstract>
   </front>
   <seriesInfo name="RFC" value="6234"/>
   <seriesInfo name="DOI" value="10.17487/RFC6234"/>
 </reference>
 
 <reference anchor="HKDF">
   <front>
     <title>Cryptographic Extraction and Key Derivation: The HKDF Scheme</title>
     <author fullname="Hugo Krawczyk" initials="H." surname="Krawczyk">
       <organization/>
     </author>
     <date year="2010"/>
   </front>
   <seriesInfo name="Lecture Notes in Computer Science" value="pp. 631-648"/>
   <seriesInfo name="DOI" value="10.1007/978-3-642-14623-7_34"/>
   <seriesInfo name="ISBN" value="[&quot;9783642146220&quot;, &quot;9783642146237&quot;]"/>
 <refcontent>Springer Berlin Heidelberg</refcontent></reference>
 
 <reference anchor="SHS">
   <front>
     <title>Secure hash standard</title>
     <author>
       <organization/>
     </author>
     <date year="2015"/>
   </front>
   <seriesInfo name="DOI" value="10.6028/nist.fips.180-4"/>
 <refcontent>National Institute of Standards and Technology (U.S.)</refcontent></reference>
 
 
 
 
     </references>
 
 
 
 <?line 651?>
 
 <section anchor="change-log"><name>Change log</name>
 
 </section>
 <section numbered="false" anchor="acknowledgments"><name>Acknowledgments</name>
 
 <t>[ TBD ]</t>
 
 <t>This work was supported in part by the German Federal Ministry of
 Education and Research (BMBF) within the project Concrete Contracts.</t>
 
 </section>
 
 
   </back>
 
 <!-- ##markdown-source:
 H4sIAAAAAAAAA80823bbOJLv/Aq080KmRd3suBNt1LOO7cSexHKO7UxmNuO1
 IBKSuKZILS+x1Yn7y+Ztf2yrCgAJ0rTs3LpHJyeWwEKhUPcqQHJd1/o4YJuW
 lQVZKAZs42wu2KvRO3bGQ5Gwt0mcxV4cblh+7EV8ARB+wqeZO8tFlnrz+MrN
 ENBdKkDL45mYxclqwIJoGltWsEwGLEvyNOt3u8+6fesqTi5nSZwvEcIXSwH/
 RZmVZongi+rYpVgBtD+wGHMZrUPvvGS1zOJZwpfzFQ0Ij6dzerfkqwXMTC3r
 0UcR5WJgPWIsEct4wOZZtkwHnc4syNqzKI9E1o6TWSdM/S4Q1obhDgKHQH+a
 leDwvAG8Y1k8z+ZxArS5sDJjkjlHwWUc8oC9+r9/SfbQM5g4YGfv9theIlLY
 GXsXBR9FkgbZisVTdia8eRSH8WxF0HwyScRHnKDhaRgZJICwAxEu5nGY/QYD
 bdbr0kMPUA0q4F7sAz17brfX3X6mRvIoQ8G8EsmCR3IxseBBOGALSXe7EOt/
 ZrnrS3RtX1hWFMOcDKhGYZy83O139Zted0u9ffJ0+5l6u93fpNGD13svgYrj
 w3avC/+6v3Se/fLU3XS3t/pubwug3F8uNrcA8PTgtIDb7vafdkaHp2ftl4dv
 T9u9p113CxQJ1KmgwbJc1wVOAQ+4l1nWPz+wsxfv2T/P5YNF4PshUP2IHcKW
 Yz/3siCOKmAvxBVPBMvmPIP/gpSBgueoOwzep1kQhgw11Q0i1O0ZsCJlPPLZ
 gq+Ak1HGg4iJJImTtG29SwUDNKs4T1h8FbEkSC9/wtVHccblyi4bb/CJtzFm
 wNEYVAwWFSwMMpHwEGUbRDM2BogxExHKzmc8ZTunu4eH7APx+xxxcPaZTao4
 gBi0uYgWQnXi7CrI5myC8KGIbO7UFhXRDJ4D/ZMVjsEUHMYPmhCOc5fc/y+R
 xPaqxeooKrAt9huAuQCOVGexuQjgXsllEOMkyFL72hl3xjSEbytoF0EULIAd
 Ub6YgPOByTijI8mMhAcy4MkKlwCTBomgtGheHmbBMhQMBr0gRT4EEbghwHGN
 6+bwCbdRX2+8GgOhPM1YGsyiYBp4HDDimpopGs34upQLMA68ASqH5AN4KICw
 J8EMQPyAR45es7ctd4vvN/vl++2t8n3/iQH0pEdQqILif/PgI7g83GKsttDb
 pj1IWHuzb37a3jI/AVbzI+Cljy1gXLoUHhpRuEIyE9DpeGGvDM5wJgfDFZuJ
 CPQzg02nQA8wQCiJAoukOj5mE2YvYp+NAEOHRipDFfFKMQGXSVU7TFwv4wh2
 GBS6e7ckkS60v0mLAe48jNkILWy3jAWBB+EqWAS4OQwA9YcHECTYyzwiX0AA
 j8Dt7LjAK/bpUTrn8ObGsn7//XdLDduLdOYw91c2x/hiHUbLPBuQ24QH+AeI
 gyG2QMWcEW+U3r9hz1n/v7d7LPYygeHoOM+KyYiNkKhpfjCDkIOzp8E18Frh
 QHrfQLAYss2+xoPEWWNEQEqCXI0JM87WmwHHsQSNPBVyp2yr3WuxJ/jfNv6H
 XNxu93HGB+Wqz9slO0BXJDvgjcEOVM1vZEev/+T78GN768H8wN3c5kcf+dFH
 fmxqfmyt4Qdx1YYkhjytr4edgk8uPaty63so0HfjWE2Dzko+KeZ5cYKuIY78
 VLvwaZAAzmKmdom3+euLaRBJx/jpk1Kcm4FkRiYWS1jf1CCLqB8yfPShO9js
 nUuiIFia8TheoutBD+AH0yk6gGkSLzSmjlJ0Y+0PkEOc4xvpuMEPQCihtcCP
 5gJEij7hSLFsB9I3dD3KGe2Ca1c+4eBoZxckO19wLVEccZGZNmSkLSD8OiOp
 AitALktEIOVyoOTiVRwP0TBVjkcGZ8XEqpwqCgIrkYKkwktERh9L7eCZilt6
 JkIiWaVK+TzjlA0k4KwxasqpVT0CMpj6q2Rao0jaFzwm8/J46OUhmUCN9SoR
 PFdMfg3U7okEAhhtueZ0MSlEBl/60xupi7gcYLpjGrNxhsPyVK4mS5MA8zH4
 mGbcjCAfVCJ6bhGjIU4r/cFIWpEEKFSckLLsX1MaSZ5g/3qJf9JMLHGTaT5D
 01LbRDrOB9YY/7pq1hjpStmYlAS0E5QT4uzVPIAopgERZR0OFHjMbG/aBqMh
 Xbtx2krdYJKd8jBrscPXRy0qpFrsDanc8esjpSapFCHCkQhJDTGXxAHSeGZz
 FsWRq1RIRnX5yPkPmly+gimAZhB2448BJDmwqEyEBaUfXCd7wGBwvpjvQdqL
 84BAw4+BliIUZOkgRR5a8sk0rhCI2TOqKrKZL8t8ABMTzMFYkenHUY1KGxI0
 NoFkW6acSlklbQ7BvlGQZf6pdLtGGopTecTaEs+HrP/kyWPwe0P2tLfddaom
 c6w2fBdeG5Z8o1A7t7wtzr5lSNM4DOOrVHnMtyevYWVTw0pdcKT3OJAOVPtf
 24yMjoVrFAhQ82xAaWhRHQUFNzNUKLK1qbpHsQ/1Ekfri6V3JQuuuH0y5puW
 dN2FrwO1y5OIDBWpIueOWgVJPpowfI5AljNI2KJ1SfzIMAykxh61WM0+mo1j
 pKV6N/KKEf3ZVvQAM/oD7OjL9L0izJGh8qAd8FynGYCHYogvYOKCFEe/DVIM
 wyHUGxOtZFx2K9DNy0Ae/Ia2khG9Shs0xJB1LT9m8CEIidznbCRpv1Z2UHem
 UESr8kzhcFqySLVHjlPsekhANhWtIwfrp7KNAsv+PGQ9bShQ6EfuizAASZxC
 JclB63U2se+DN+k9I6hmiJPTHffl3gFExCTl7tSf39A4ZJ/5chknGbLbiKC4
 pJqC6VSLLfMJCIUMACZXDUCnmSpRpDEJz3BdfA96Q9kFqFOKkpD6STVWnoIF
 oXopMF2vMVHVEViWVpnmYeiCdWBvhEItIgIK4o/AL7lse6RyCphTzykK6Ws7
 lxmfdC4uUHRzc9tdkjyHbEOyZIe9PFum73/asMiAh1rOUrqaBMcpNaDyRCjx
 w2MNW74VFu5zWFBXoNPOiKRBzqg0ApAyuh5s7tCOleFRKoN5NqbtfMYxjQGl
 B1MKvCAGvivhAH5rsmLAv2BKdqfyY8FmiaBOJchtscAkGQptsCWeQU5jzzzf
 QebLNVGCY00sMb3XruiRS0mXsCeXaUWdKL811QkAiD0TVGQkBxVHOUazdjEL
 jh+jcjpzbVI5pLJJ5RrS2G9SuReaCzC3ULjKKJBPERxkQlUFULNxnxaREAwt
 IlegkVbFRqPSCdwruiZP8O8nTl3QEkUgGczQlRncL0PtSJUItTdtkCAVR0PW
 5EatpHzQZBdWciEAIsE+l3YMst1VeBcLdwMgAPhY1mG156VcMRbcEisO2jgP
 FoX1tUjTYFYVKaHWf8GZgF/BPibmHbxMnirxWeEDkyA5yk9SjlR2ifsFqeAK
 SfpVSQIFTP2VUQ4lQxSCH1MLKlkCSENZWZUUohvK+chwRb6vOKp3Y7L0XTRp
 NBY1bgPGB5iL3gbNKTfzb2o2eaQNpqR0Xele5fH9Gh9EHwEG/hdJSl2qpFnl
 kWuPmYS/U+f/poNZVT5yWNoiyehLvVmD5k01zykcwKQfLIcsyUULqwCkBRsU
 WCcED5LKd/ZiQKmWx31+ypZ4hrg7o/TbDTlkKe4pnk0mCfbaMZ+RvRfZWC9O
 hym53QMs2Wqps9qdBebJliX/AisSUZ7amH0c7M7GKXXtZffSXcbgu2SFlVpV
 qYxpdIyTMAnCuiwSMzoULBzekidZcagFXGVeniQi8lYtiw59phiRIZceq8IT
 KMkjdeYD0mXzPPIToHARhCGAgSnbPeE+de7ASdmV/lhQtun2eur4zptzXBE7
 mAEeaxeZXIkF0rH3cxEJ1FLd5cLn+lS9JReG9C5ZlVwsT/wiNubEZ9QqS58x
 yaG2LFVVxrvZ18OaDfhEH/XhMZF6rElzxqoXfhaAsWV8sQQB70zSOMyxXVsM
 3hIwMMI47GJXcwEAeI5WbTVb8uDPg1pYeDSWBnjONO49+6Xrdnvwj3W7g26X
 7e6fno2ZjfDvRod/Z2IZe3OnTWk21bxQbcqKfdy9fll7jUvaUrZBnN5oW89/
 cl2r0wEy/HgAghLeJdXwQtABLEiWiPUy60SEUsu+Zsdg6YWqmVv9KtohJVLU
 u+6v6pjCqCh3wlB7xbSSFJQWB+SDhVAbiLO54Hh8qY60lWIGAAQVN3LA4upM
 IZWpStF2gMQ1AcMFzYJ9J2IGRirQbCDMv9oZ7SgVtj68Gr2LIDAWNLK3cl56
 bhdXMnjEzUsW8q1beM1UjVyUI+15tgghNNG6yarNcN+0PTcR0qMq+lK1X6ib
 el1QI5KqrMKmoOl+QajGxdI4T7wKfUHWpusnbSBCURtkHbyQ0UBrQRMozqOo
 3+/pvi6ywD1KZ5pzVDE2xzcFYcQyPVJlNmwKmd0UE6WgwJHa4toL20rQTkUn
 mqMYVJTLUIB1a0w2WORdGKoBDRtOTSmGjDTKAeGlBNy54ZMKXfpMUZqQFnYJ
 cSnE+m6JV2ZSKJHIUFvsMoIFIFnIFxSA3oNC+wm/4qEsva8w782KM2wwzoj9
 yrrogKDcZvYY/34IzscO6USCJ9xphmDjku8IR7kV6p4EpsCMXgj4Cjn1TEAM
 yLIkmOQUpaQZqzM0uRT3wI1QpohH+YDem8NmjZqdTiPsMX2mRaRnyOKs8AtI
 4lWxQzYVIBbdgQWTM+mh004Tt2Mt8jQjoaliAMoq2C7gUXRKpw+WEidl9AFH
 PAuphSGSj6pngQVZSYZSbLO1qLh+70sTa5EUmd56G7KT5gl1OMhTa11NUJ4H
 vj5bP7trXj+vm/kZ0gGnYAomjkrDMBivoeBb1vz6fdYHjBWZPeHRJeSsPEqn
 aNfGs18b1rTTfPI/EAsHevMoK50vDFRH/PtS2wy3lo/AyQei+awdCrMrG9L5
 0h9LTQN96xVmjdqQkvYd8j6mdtL9GV20NtLxLWt+/T7rA9XlWEc7HFZ90KSk
 +KqKU3n59vyCfEfrfmqlv1fzqBjtOj9kn81w90ng4fptbyodCNI055hV86hM
 5P5oehoovDXzuSl3M+7WRP8tUmjezxr/W8wEjm4pjubRekP6bmtSKiRLCRuD
 L1T7LYrAmFJBcgbpLp7byVJOhuM18cmW4RkANcCQ7ft7pzvua7ECONux6k5R
 O8TyTEOFeJ9aRanOcUzfIpthKaQMdENUnhdT3oRnHJi76n4ZpipGWkNnmWXv
 Enta15gLQWpJ13Jxo+EKSyZ+SagBFpPVRVEO+wLqmFAVkVRbVtYL8CIpltlY
 REFKT6cwPFqxGGBl70DV9ItgNqecSSVrMustVsPzS32vJFypROhep1vyX5J1
 ocgaqnNlvLhZiqACYyFieC98NAd1sKnS58BpVYFbbEPeyy956+J81y+u12y0
 6LaAMjKaJRGb63zY7A/OLe1CMeeqAww2+wYAJG9aoV6J7G0+sc25jlVzxsbN
 MLWTrlEU9PC9mRhqahUWo20pT0I0LoMcPNmt7rBVQwn1Rhfp0MXZ+503b/bP
 Lk72T/dP/rZ/8f7w7GDvZOd9izyOjdWGXSAoWiuVUcjNLzTf5Xni52KbxZsK
 EeWeu9e06+o+NRJ9X7h73a1MufXJcbBx3i1kQScKRVQESVDp2VU2TZq7NlTY
 OlsHxdWEA/I9fOu+iePLfGnXRAuypnZKJbHHHF5aBF6TMHQTSrwAKg81RxKt
 GsKVYK67wxq79mKv/7GLZX6Wpyy+xOoG8cs2ThWyPeEhbe/XYYMo2c/sDinW
 p7tfNr0Sykq1JbnU0o1KhVP6gpJZhtAaolHpYbRA5BFK/RjEpOheG5EsrHXq
 m63NWLWOpYgsxV5ryxbdZ/ZWfo/n68vLhUhQYzNVXuqP95WXJRyWl3JMtvC1
 Ld49t2gH4LeQsvjPyhO/ID0EVyO/vGBWsH/M6g303J0MMpvIbH8K/FYWX4ro
 Lzdmtfr9k8H7MzNdYkUxeoOHdQC+fc36wH0z7p6pOdshzqadT5LDgX/T8UIe
 LBR77yqx6GXT5qVjlmJxTMA/sVD60hIpkvd/v58Z/ChLQJFpcikQVuuiH2AJ
 9yqmLovUVy/xhiVk0Q8xhm9Zsz7wkD02z1xjCbClgr9rLQFekArQMSaGsR9I
 bTNcEx+/wAaeOExRr87A/oh1GyhZq/dSSrdU/gfq/XolJL3fLvWe7ujpO7hr
 1/+WNc12gNEFYEYXAPKPOAy8lTwyULU6HvHj/TijRXAr9Ns6+wGgK0jHL9SV
 NlWa9vpPyxxOTh4yG0Iy3sPxhL5hLiMB9igUBrPKaIqYZcYqH93ZkVDhBjOz
 W18YEpULTHhTgKDlLQs6ysa+AVYFdIwBFb9kYu2gvW0dxFfYH6Cr216ch35x
 XVOBTnM6j8tiuuYt8Au/QN88WKqTeMkZ6qrLA/aWJSKOme4M8bgepzPJ3Jvj
 MdlGHlG8hacbWLfobnyiuhsKG/YoVIcCFkOceDEOr5mrmwRaC7VOgD6oq8Pq
 hAfLg4+Bn9PF8SBK22bddzv+mbowv0BZ6pZDIVeV57bYhoZ18Vl5FKo6DMWN
 7/LsHL+HOs0h9fcF94EzQqmL/mgVJA3N3E/qGamZSgNbRtYtyWw9fBVd1+jF
 2nIlQo3fT6MlClLaWjuLrKdQTA0CnDIIL+ojEF2EF9z/eno8sjWAQ50Hs/Fw
 tH+ye7AzOrvYPR6dnezsnuGWCnB1E86o5yu1ijxLrpaGTRHZKA9vl9pmlXS7
 1m5mhHV2vHc8YH6cT0JQboKkW6/yOi4N/MXS4WXIdkH5TkUov4tZcKP9qZAj
 CRnye4kXT55zX7AjnlzuBUm2Ymi2yDpZSdfbNrvHh6OLvf23x6eHZ7plY0il
 2kMx2iooKNVIKWhSev+5foSgphVwhcKZgzXVU3PKJKHeK1BPCrjbj/Bs3Cxj
 a4TLno/kiqElZv+NZEp1tkHHsKjH259Q7li4q42CeelbQvokhGYbhbyRiqq+
 QZEFGcp4K8Ew3Ysckd0UPdm4nTQclkwl3VAT9iSwnuTArDst6u3OP4724e/x
 62+yqTui/RfZku5wKPIrHQ49p/OQLkftAF1/vK/DUcKVHY6Hdkcek1aQ65MD
 KgAYIQH22Dd5rABLRXmsFYGOA3Sfp57nrN+6Abj2gLsz4Zk3d/WKZprVeMBd
 eqMyhlQiRqtm1TcNhJd7b7GqEkje3EU409zUHDJTqLVb/npm3QX5WHfnKx1e
 TVgb/UXZ530oUmkkpQ7VusEKedEKfjDamru+K035arap1z1ZzhdyoeIrKnzV
 /qJHCtP7Ysx3dGnrazjfypAKwrLbK1u9X0Yzih9vaKf4w094Mfyh03Ug0rqT
 CLxohWdhyaWL2B7uWVIgxc9DvN5rXIp58HTtVi/KZAATpCv74bwAHm5Wo1HF
 V5NSbD4cXf11V3VN67aaNvA9quuGyGhGKrkp0vRNpzrTqHTHCLT2fiECmJF/
 /+8Y+F/tYy798vDkaG1KeDvhMxMrlZE18MeYWa1e5Ix7UkFMeAqPqtMd5moH
 aSR+9TPEYhb5h3pa6OgcA3/wJE/wN8Z28Q69r0q7VP0M1h79DNYjdoiXdesQ
 ozjCH8xA9Zhw75J+aUfeLQzjGX7a8dB7h8Kfyd9b+zSQP9ok/OHGlIep2Lip
 rENH+PSbSVf0qwr0zVZZVNN9fXWFUf40GXspfPpdrCP6cnCCBb217+deeaJ+
 IlLBYdfMfnH04qX8UntZy+M1NdwTnisJfEOCgJr3/wGYuY3z8E4AAA==
 
 -->
 
 </rfc>