--- a/Overview.html Mon Jan 07 12:36:03 2013 -0500
+++ b/Overview.html Mon Jan 07 15:14:16 2013 -0500
@@ -23,7 +23,7 @@
<link rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/W3C-WD" type="text/css" /></head>
<body>
- <div class="head"><div><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" width="72" height="48" alt="W3C" /></a></div><h1>Web Cryptography API Use Cases</h1><h2>W3C Working Draft <em>8 January 2013</em></h2><dl><dt>This Version:</dt><dd><a href="http://www.w3.org/TR/2013/WD-webcrypto-usecases-20130108">http://www.w3.org/TR/2013/WD-webcrypto-usecases-20130108</a></dd><dt>Latest Published Version:</dt><dd><a href="http://www.w3.org/TR/webcrypto-usecases">http://www.w3.org/TR/webcrypto-usecases</a></dd><dt>Latest Editor’s Draft:</dt><dd><a href="http://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html">http://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html</a></dd><dt>Previous Version(s):</dt><dd><a href="http://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html">http://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html</a></dd><dt>Editor:</dt><dd><a href="http://arunranga.com/">Arun Ranganathan</a>, Mozilla Corporation <arun@mozilla.com></dd><dt>Participate:</dt><dd></dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2013 <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>, <a href="http://www.ercim.org/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr />
+ <div class="head"><div><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" width="72" height="48" alt="W3C" /></a></div><h1>Web Cryptography API Use Cases</h1><h2>W3C Working Draft <em>8 January 2013</em></h2><dl><dt>This Version:</dt><dd><a href="http://www.w3.org/TR/2013/WD-webcrypto-usecases-20130108/">http://www.w3.org/TR/2013/WD-webcrypto-usecases-20130108/</a></dd><dt>Latest Published Version:</dt><dd><a href="http://www.w3.org/TR/webcrypto-usecases/">http://www.w3.org/TR/webcrypto-usecases</a></dd><dt>Latest Editor’s Draft:</dt><dd><a href="http://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html">http://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html</a></dd><dt>Previous Version(s):</dt><dd><a href="http://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html">http://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html</a></dd><dt>Editor:</dt><dd><a href="http://arunranga.com/">Arun Ranganathan</a>, Mozilla Corporation <arun@mozilla.com></dd><dt>Participate:</dt><dd></dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2013 <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>, <a href="http://www.ercim.org/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr />
<div class="section">
<h2>Abstract</h2>
@@ -92,7 +92,7 @@
This document was produced by a group operating under the
<a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February
2004 W3C Patent Policy</a>. W3C maintains a
- <a href="http://www.w3.org/2004/01/pp-impl/42538/status">public list of
+ <a href="http://www.w3.org/2004/01/pp-impl/54174/status">public list of
any patent disclosures</a> made in connection with the deliverables of
the group; that page also includes instructions for disclosing a patent.
An individual who has actual knowledge of a patent which the individual
@@ -129,13 +129,14 @@
<li><p><dfn id="export">EXPORT</dfn>, the ability to export a key or key pair that can be accessed from within the application that is invoking the export function. This necessiates an interoperable key format, which may be represented as octets, that other web applications can then import.</p></li>
<li><p><dfn id="keyexchange">KEYEX</dfn>, the ability for two entities to exchange key(s) without interception by a third party, with <dfn id="keyex-dh">KEYEX-DH</dfn> representing Diffie-Hellman key exchange, a common application of safe key exchange.</p></li>
<li><p><dfn id="keycall">KEYCALL</dfn>, the ability to access a particular key (or key pair) from within a web application's key storage, which is within the web application's origin only. Here, the key storage might be IndexedDB or localStorage, and the key or key pair might have been created by the web application or imported by the web application.</p></li>
- <li><p><dfn id="sym">-SYM</dfn>, an abbreviation for <dfn id="sym">symmetric key cryptographic operations</dfn>, used in this document as a suffix to other features to specifically clarify the feature being invoked by the web application.</p></li>
- <li><p><dfn id="assym">ASSYM</dfn>, an abbreviation for <dfn id="assym">assymetric key cryptographic operations</dfn>, typically involving a public and private key pair, used in this document as a suffix to other features to specifically clarify the feature being invoked by the web application.</p></li>
+ <li><p><dfn id="sym">-SYM</dfn>, an abbreviation for <em>symmetric key cryptographic operations</em>, used in this document as a suffix to other features to specifically clarify the feature being invoked by the web application.</p></li>
+ <li><p><dfn id="assym">ASSYM</dfn>, an abbreviation for <em>assymetric key cryptographic operations</em>, typically involving a public and private key pair, used in this document as a suffix to other features to specifically clarify the feature being invoked by the web application.</p></li>
<li><p><dfn id="random">RANDOM</dfn>, the ability to generate cryptographically secure random numbers.</p></li>
</ul>
<p>Additionally, the Web Cryptography WG is actively discussing three other features:</p>
<ul>
- <li><p><dfn id="WRAP">WRAP</dfn> which allows a web application to use a key to <em>wrap another key</em>, so that the wrapped key can be unwrapped by a party with the corresponding wrapping key, but is hard to obtain or unwrap by anyone without the corresponding wrapping key. While it is possible to create a key-wrapping and unwrapping mechanism with the other features listed, this feature provides a way to do so without exposing the key to be wrapped to JavaScript. <div class="ednote"><div class="ednoteHeader">Editorial note</div>Would WRAP and UNWRAP benefit from -SYM or -ASSYM qualifiers?</div></p></li>
+ <li><p><dfn id="WRAP">WRAP</dfn> which allows a web application to use a key to <em>wrap another key</em>, so that the wrapped key can be unwrapped by a party with the corresponding wrapping key, but is hard to obtain or unwrap by anyone without the corresponding wrapping key. While it is possible to create a key-wrapping and unwrapping mechanism with the other features listed, this feature provides a way to do so without exposing the key to be wrapped to JavaScript. </p>
+ <div class="ednote"><div class="ednoteHeader">Editorial note</div>Would WRAP and UNWRAP benefit from -SYM or -ASSYM qualifiers?</div></li>
<li><p><dfn id="UNWRAP">UNWRAP</dfn> which allows a web application to use a key to unwrap another encrypted key or key pair, which can then be used in standard cryptographic operations. While it is possible to create a key-wrapping and unwrapping mechanism with the other features listed, this feature provides a way to do so without exposing the key to be wrapped to JavaScript.</p>
<div class="ednote"><div class="ednoteHeader">Editorial note</div><p>This feature is subject to discussion, including further work by the JOSE WG. See <a href="https://www.w3.org/2012/webcrypto/track/issues/35">ISSUE-35</a> logged by the WebCrypto WG.</p></div>
</li>
@@ -186,7 +187,7 @@
</code></pre></div></div>
</div>
- <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>].
+ <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>]. </p>
<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">
@@ -255,7 +256,7 @@
</code></pre></div></div>
</div>
- His browser presents this key every time he accesses the website and enters his password, which effectively binds his username and password to the generated private key. Additionally, Jae-sang can digitally sign online checks, authorize payments, and sign tax forms that he submits to the bank site using this generated key [<a href="#sign">SIGN</a>]. He can also perform the following tasks, following an authentication cycle such as the one described above:</p>
+ <p>His browser presents this key every time he accesses the website and enters his password, which effectively binds his username and password to the generated private key. Additionally, Jae-sang can digitally sign online checks, authorize payments, and sign tax forms that he submits to the bank site using this generated key [<a href="#sign">SIGN</a>]. He can also perform the following tasks, following an authentication cycle such as the one described above:</p>
<ol>
<li><p>Receive encrypted documents from GB via HTTP that only he can read, with the assurance that they have come from GB and only GB. These include his private bank statements and tax documents, which are signed with his public key, already obtained in a previous step. [<a href="#verify">VERIFY</a> | <a href="#UNWRAP">UNWRAP</a>| <a href="#decrypt-sym">DECRYPT-SYM</a> ].</p></li>
<li><p>Submit documents to GB that only GB can read, with the assurance that these have come from Jae-sang. Such documents include confidential financial information, and may be encrypted at submission. [<a href="#sign">SIGN</a> | <a href="#derive-sym">DERIVE-SYM</a> | <a href="#encrypt-sym">ENCRYPT-SYM</a> | <a href="#wrap">WRAP</a>]</p></li>
@@ -266,7 +267,7 @@
<h3>3.2. Video Services</h3>
<p>A Video Service Provider wishes to distribute high quality commercial video to users of web-enabled TVs and Set Top Boxes. The video in question can only be delivered to devices with certain capabilities that meet the service provider's security requirements, which may vary based on the content and content quality to be delivered. In order to determine whether the device is indeed approved to be used with the video service, the service provider arranges for suitable devices to each be pre-provisioned with a cryptographic key and associated identifier by the device manufacture, which are made known to the service provider.</p>
-<p>Ryan has just bought a new TV and wishes to watch video content from the service provider. He connects the TV to the Internet, and navigates to the video provider's website. The video provider's site establishes a secure communication channel between the video provider's page on the TV and the video provider's servers, proving to the servers that Ryan's TV is indeed one of those that meets the security requirements by use of the cryptographic key and identifier pre-provisioned on the TV. The video provider's page on the TV likewise verifies that it is talking to a genuine server, preventing the hijacking of Ryan's video watching by a malicious third party. To ensure the highest security, the pre-provisoned key is used minimally in this process to deliver session keys. <p>[<a href="#namedkey">NAMEDKEY</a> | <a href="#verify">VERIFY</a> | <a href="#unwrap">UNWRAP</a> | <a href="#mac">MAC</a> | <a href="#encrypt-sym">ENCRYPT-SYM</a> | <a href="#decrypt-sym">DECRYPT-SYM</a> | <a href="#sign">SIGN</a>]</p></p>
+<p>Ryan has just bought a new TV and wishes to watch video content from the service provider. He connects the TV to the Internet, and navigates to the video provider's website. The video provider's site establishes a secure communication channel between the video provider's page on the TV and the video provider's servers, proving to the servers that Ryan's TV is indeed one of those that meets the security requirements by use of the cryptographic key and identifier pre-provisioned on the TV. The video provider's page on the TV likewise verifies that it is talking to a genuine server, preventing the hijacking of Ryan's video watching by a malicious third party. To ensure the highest security, the pre-provisoned key is used minimally in this process to deliver session keys.</p> <p>[<a href="#namedkey">NAMEDKEY</a> | <a href="#verify">VERIFY</a> | <a href="#unwrap">UNWRAP</a> | <a href="#mac">MAC</a> | <a href="#encrypt-sym">ENCRYPT-SYM</a> | <a href="#decrypt-sym">DECRYPT-SYM</a> | <a href="#sign">SIGN</a>]</p>
<div class="example"><div class="exampleHeader">Example</div>
<p>The <a href="#KeyDiscovery">Key Discovery API</a> describes the provides a mechanism for an application in JavaScript to detect the presence of a pre-provisioned key using the name of a disclosed identifier. </p>
<div class="ednote"><div class="ednoteHeader">Editorial note</div><p>While <code>KeyOperation</code> is asynchronous and event driven, the key retrieval mechanism is synchronous; this might change in subsequent drafts.</p></div>