--- a/Overview-UseCases.xml	Thu Dec 06 18:10:05 2012 -0500
+++ b/Overview-UseCases.xml	Thu Dec 06 18:14:26 2012 -0500
@@ -132,14 +132,14 @@
       <p>Park Jae-sang opens up a bank account with Gangnam Bank (GB), and wishes to log-in and engage in online transactions, including account balance checking, online payments (with some automated scheduled payments), and account transfers between domestic and investment accounts.  The first time Park logs in to the GB website with a temporary verification code sent to his cell phone, the bank asks him to ascertain if the browser he is using is not at a kiosk; moreover, he is asked if it is a web browser and machine configuration he will use often.</p>
       <p>He confirms that it is.  The GB web site then asks him to generate a public key/private key pair, along with a digital certificate.  Park consents, and the web page creates the key pair, storing his private key in the browser's designated key store, along with a one-time key escrow by the bank.  Additionally, Jae-sang is presented with the bank's public key, such that documents issued by the bank can be verified and decrypted.  Jae-sang is also presented with a user guide that explains the validity period of the certificate, and for how long it will persist.  [<a href="#derive">DERIVE</a> | <a href="#keyex-dh">KEYEX-DH</a>].</p>
       <div class="example">
-      <p>GB may first generate a key pair for Jae-sang.  This is the public key/private key pair which will be used in subsequent transactions.</p>
+      <p>GB may first generate some key pairs for Jae-sang.  These include the public key/private key pair which will be used for digital signatures.</p>
       <x:codeblock language="es">
-        <span class="comment">// TODO add derivation for ECDH </span>
+        <span class="comment">// TODO add derivation for RSASSA-PKCS1-v1_5 key pair generation </span>
 
       </x:codeblock>
-      <p>GB may then use a key exchange mechanism to exchange keys with the server.  This includes making sure that the client (Jae-sang) obtains a copy of GB's public key, and that GB obtains a copy of Jae-sang's public key. </p>
-      <x:codeblock>
-        <span class="comment">// TODO add DHKE code </span>
+      <p>GB may then use a key exchange mechanism to exchange keys with the server.  This includes making sure that the client (Jae-sang) obtains a copy of GB's public key, and that GB obtains a copy of Jae-sang's public key, which were generated in the preceding step. </p>
+      <x:codeblock language="es">
+        <span class="comment">// TODO add some Diffie-Hellman code </span>
       </x:codeblock>
       </div>
       <p>Subsequent access to the GB website -- always over TLS -- is triggered via presentation of the key and certificate that Jae-sang generated when he first accessed the website.  JavaScript initially loaded by GB contains a message that only Jae-sang can decipher, since it is encrypted with his public key; moreover, that message is signed by GB, which gives the client confidence that the message originates from GB.  The message is deciphered, and the deciphered message is then digitally signed and sent back to the GB server.  This establishes identity with non-repudiation.  [<a href="#keycall">KEYCALL</a> | <a href="#verify">VERIFY</a> | <a href="#decrypt-pki">DECRYPT-PKI</a> | <a href="#sign">SIGN</a>].