Expunged mention of certificate since API does not include certificates
author"arangana <arun@mozilla.com>"
Tue, 18 Dec 2012 16:45:09 -0500
changeset 12 32af89439e8c
parent 11 3928f44f808f
child 13 9b8cf5a8851a
Expunged mention of certificate since API does not include certificates
Overview-UseCases.xml
Overview.html
--- a/Overview-UseCases.xml	Mon Dec 17 13:32:37 2012 -0500
+++ b/Overview-UseCases.xml	Tue Dec 18 16:45:09 2012 -0500
@@ -142,7 +142,7 @@
       <div id='banking' class='section'>
       <h3>Banking Transactions</h3>
       <p>Park Jae-sang opens up a bank account with Gangnam Bank, 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 Gangnam Bank website (Gangnam Bank's website from now on will be abbreviated "GB") 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.  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 presents the derived public key to GB.  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>
+      <p>He confirms that it is.  The GB web site then asks him to generate a public key/private key pair.  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 presents the derived public key to GB.  Jae-sang is also presented with a user guide that explains the validity period of the key pair, and for how long they will persist.  [<a href="#derive">DERIVE</a> | <a href="#keyex-dh">KEYEX-DH</a>].</p>
       <div class="example">
       <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">
@@ -177,7 +177,7 @@
          
       </x:codeblock>
       </div>
-      <p>Subsequent access to the GB website -- always over <a href="#TLS">TLS</a> -- 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-ASSYM</a> | <a href="#sign">SIGN</a>].  
+      <p>Subsequent access to the GB website -- always over <a href="#TLS">TLS</a> -- is triggered via use of the key 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-ASSYM</a> | <a href="#sign">SIGN</a>].  
       <div class="example">
        <p>In the example below, an encrypted message is signed by GB.  The signature is verified, and upon successful verfication, is decrypted.  The decrypted message is then signed and sent to GB.  This example should be seen as a simplification for illustrative purposes only, since assymetric encryption and decryption isn't recommended, and techniques such as key wrapping should be used [+<a href="#unwrap">UNWRAP</a>].</p>
        <x:codeblock language="es">
--- a/Overview.html	Mon Dec 17 13:32:37 2012 -0500
+++ b/Overview.html	Tue Dec 18 16:45:09 2012 -0500
@@ -158,7 +158,7 @@
       <div id="banking" class="section">
       <h3>3.1. Banking Transactions</h3>
       <p>Park Jae-sang opens up a bank account with Gangnam Bank, 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 Gangnam Bank website (Gangnam Bank's website from now on will be abbreviated "GB") 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.  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 presents the derived public key to GB.  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>
+      <p>He confirms that it is.  The GB web site then asks him to generate a public key/private key pair.  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 presents the derived public key to GB.  Jae-sang is also presented with a user guide that explains the validity period of the key pair, and for how long they will persist.  [<a href="#derive">DERIVE</a> | <a href="#keyex-dh">KEYEX-DH</a>].</p>
       <div class="example"><div class="exampleHeader">Example</div>
       <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>
       <div class="block"><div class="blockTitleDiv"><span class="blockTitle">ECMAScript</span></div><div class="blockContent"><pre class="code"><code class="es-code">
@@ -193,7 +193,7 @@
          
       </code></pre></div></div>
       </div>
-      <p>Subsequent access to the GB website -- always over <a href="#TLS">TLS</a> -- 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-ASSYM</a> | <a href="#sign">SIGN</a>].  
+      <p>Subsequent access to the GB website -- always over <a href="#TLS">TLS</a> -- is triggered via use of the key 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-ASSYM</a> | <a href="#sign">SIGN</a>].  
       <div class="example"><div class="exampleHeader">Example</div>
        <p>In the example below, an encrypted message is signed by GB.  The signature is verified, and upon successful verfication, is decrypted.  The decrypted message is then signed and sent to GB.  This example should be seen as a simplification for illustrative purposes only, since assymetric encryption and decryption isn't recommended, and techniques such as key wrapping should be used [+<a href="#unwrap">UNWRAP</a>].</p>
        <div class="block"><div class="blockTitleDiv"><span class="blockTitle">ECMAScript</span></div><div class="blockContent"><pre class="code"><code class="es-code">