--- a/Overview.html Fri Dec 21 13:50:26 2012 -0500
+++ b/Overview.html Fri Dec 21 14:17:02 2012 -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>02 January 2013</em></h2><dl><dt>This Version:</dt><dd><a href="http://www.w3.org/TR/2013/WD-webcrypto-usecases-20130102">http://www.w3.org/TR/2013/WD-webcrypto-usecases-20130102</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>02 January 2013</em></h2><dl><dt>This Version:</dt><dd><a href="http://www.w3.org/TR/2013/WD-webcrypto-usecases-20130102/">http://www.w3.org/TR/2013/WD-webcrypto-usecases-20130102</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="https://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html">https://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html</a></dd><dt>Previous Version(s):</dt><dd><a href="https://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html">https://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.eu/"><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>
@@ -45,7 +45,7 @@
reports index</a> at http://www.w3.org/TR/.
</em></p><p>
This document is the 02 January 2013 <b>First Public Working Draft</b> of the
- <cite>Web Cryptography API Use Cases</cite> specification.
+ <cite>Web Cryptography API Use Cases</cite> document.
Please send comments about this document to
<a href="mailto:public-webcrypto@w3.org">public-webcrypto@w3.org</a>
@@ -81,7 +81,7 @@
This document is produced by the <a href="http://www.w3.org/2012/webcrypto/">Web Cryptography Working Group</a>, within
the W3C <a href="http://www.w3.org/Interaction/">Interaction Domain</a>.
Changes made to this document can be found in the
- <a href="https://dvcs.w3.org/hg/webcrypto-usecases">W3C public Mercurial Repository</a>.
+ <a href="https://dvcs.w3.org/hg/webcrypto-usecases/">W3C public Mercurial Repository</a>.
</p>
<p>
Publication as a Working Draft does not imply endorsement by the
@@ -127,7 +127,7 @@
<li><p><dfn id="derive">DERIVE</dfn>, the ability to derive a key or key pair used in cryptographic operations; <dfn id="derive-assym">DERIVE-ASSYM</dfn> is the ability to derive assymetric keys, typically a public and private key pair, for use with assymetric cryptographic operations, and <dfn id="derive-sym">DERIVE-SYM</dfn> is the ability to derive a symmetric key for use with symmetric cryptographic operations.</p></li>
<li><p><dfn id="import">IMPORT</dfn>, the ability to import a key or key pair that have already been created elsewhere, for use within the web application that is invoking the import function, for use within the importing web application's origin. This necessiates an interoperable key format, which may be represented as octets.</p></li>
<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="keyex">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>
@@ -135,12 +135,12 @@
</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="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>
+ <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="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>
- <li><p><dfn id="NAMEDKEY">NAMEDKEY</dfn> which allows an application in JavaScript to discover a <dfn id="pre-prov">pre-provisioned</dfn> key within the scope of the application's origin, which exists at the time of the application's first invocation, and has not been derived, generated or imported by the application using any of the features listed above; such keys may have been provisioned by a device manufacturer, for example, and the JavaSript application can access them for initial authorization and authentication at time of first invocation. </p>
+ <li><p><dfn id="namedkey">NAMEDKEY</dfn> which allows an application in JavaScript to discover a <dfn id="pre-prov">pre-provisioned</dfn> key within the scope of the application's origin, which exists at the time of the application's first invocation, and has not been derived, generated or imported by the application using any of the features listed above; such keys may have been provisioned by a device manufacturer, for example, and the JavaSript application can access them for initial authorization and authentication at time of first invocation. </p>
<div class="note"><div class="noteHeader">Note</div><p>This feature is developed in the <a href="#KeyDiscovery">Key Discovery API</a>.</p></div>
</li>
</ul>
@@ -186,7 +186,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-assym">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">
@@ -257,7 +257,7 @@
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>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>
</ol>
<p>If GB wishes to "cache" aspects of reusuable authentication code, but cannot avail of a code signing system, GB can employ a similar data integrity mechanism that the <a href="#data-integrity">social networking site uses</a>. Moreover, Jae-sang or GB may at any time reinitiate a key generation operation for subsequent transactions; GB will determine the validity of the keys in question.</p>
@@ -353,7 +353,7 @@
</code></pre></div></div>
<p>In this case, <code>getHashFromServer()</code> is guaranteed to be untampered with, since it connects to the server or the HTTP cache, which are above suspicion in this threat model.
</p>
- <div class="note"><div class="noteHeader">Note</div><p>The conversion to an <a href="#TypedArrays"><code>ArrayBufferView</code></a> must be consistent with the conversion to bits on the server side, so that the SHA-256 digests can be compared acurately.</p></div>
+ <div class="note"><div class="noteHeader">Note</div><p>The conversion to an <a href="#TypedArray"><code>ArrayBufferView</code></a> must be consistent with the conversion to bits on the server side, so that the SHA-256 digests can be compared acurately.</p></div>
</div>
<p>Since their threat model trusts the network layer (which includes <a href="#TLS">TLS</a>, and a distributed web cache not entirely on their own servers) but mistrusts the user's machine to store code via <a href="#localStorage"><code>localStorage</code></a> and <a href="#IndexedDB"><code>IndexedDB</code></a> the <a href="#WebCrypto">WebCrypto API</a> offers mitigations:</p>
<ol>
@@ -437,7 +437,7 @@
<h3>3.6. Documents In the Cloud</h3>
<p>Vijay wishes to confidentially store certain documents of various file types using a web service that he pays a monthly subscription to for such confidential storage. The confidential storage web application (abbreviated "SWA") makes the claim that all storage is encrypted, and that even it cannot access the contents of what a user stores. He can drag and drop content from his laptop onto a web page of the service, and it automatically encrypts it and stores it in an encrypted manner. Vijay can do the following:</p>
<ol>
- <li><p>Log on to the service using his credentials; after the service determines that Vijay is using his primary browser, which he will use to access the service subsequently, it generates both signature and encryption key pairs. Derivation may be similar to the <a href="#banking">banking use case</a>. [<a href="#derive-assym">DERIVE-ASSYM</a> | <a href="keyex-dh">KEYEX-DH</a> | <a href="#verify">VERIFY</a> | <a href="#unwrap">UNWRAP</a> | <a href="#decrypt-sym">DECRYPT-SYM</a> | <a href="#sign">SIGN</a>] </p></li>
+ <li><p>Log on to the service using his credentials; after the service determines that Vijay is using his primary browser, which he will use to access the service subsequently, it generates both signature and encryption key pairs. Derivation may be similar to the <a href="#banking">banking use case</a>. [<a href="#derive-assym">DERIVE-ASSYM</a> | <a href="#keyex-dh">KEYEX-DH</a> | <a href="#verify">VERIFY</a> | <a href="#unwrap">UNWRAP</a> | <a href="#decrypt-sym">DECRYPT-SYM</a> | <a href="#sign">SIGN</a>] </p></li>
<li><p>Drag over content from his underlying file system that he wishes to store. The SWA encrypts the content, and uploads it. It may make multipart cryptographic operations on a given file, and it may also "chunk upload" large content, depending on file-size. [<a href="#sign">SIGN</a> | <a href="#hmac">HMAC</a> | <a href="#derive-sym">DERIVE-SYM</a> | <a href="#encrypt-sym">ENCRYPT-SYM</a> | <a href="#keycall">KEYCALL</a> | <a href="#wrap">WRAP</a>] </p>
<div class="example"><div class="exampleHeader">Example</div>
<p>Multipart cryptographic operations can be performed with the same key.</p>
@@ -456,15 +456,15 @@
<h2>4. References</h2>
<dl class="bibliography">
<dt id="WebCrypto">Web Cryptography API</dt>
- <dd><cite><a href="http://dvcs.w3.org/hg/webcrypto-api/">Web Cryptography API</a></cite>, D. Dahl, R. Sleevi. W3C</dd>
+ <dd><cite><a href="https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html">Web Cryptography API</a></cite>, D. Dahl, R. Sleevi. W3C</dd>
<dt id="KeyDiscovery">WebCrypto Key Discovery API</dt>
- <dd><cite><a href="http://dvcs.w3.org/hg/webcrypto-keydiscovery">WebCrypto Key Discovery</a></cite>, M. Watson. W3C</dd>
+ <dd><cite><a href="https://dvcs.w3.org/hg/webcrypto-keydiscovery/raw-file/tip/Overview.html">WebCrypto Key Discovery</a></cite>, M. Watson. W3C</dd>
<dt id="localStorage">Web Storage</dt>
<dd><cite><a href="http://dev.w3.org/html5/webstorage/">Web Storage</a></cite>, I. Hickson. W3C</dd>
<dt id="IndexedDB">IndexedDB</dt>
- <dd><cite><a href="http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html">Indexed Database API</a></cite>, N. Mehta, J. Sicking, E. Graff, A. Popescu, J. Orlow. W3C</dd>
+ <dd><cite><a href="https://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html">Indexed Database API</a></cite>, N. Mehta, J. Sicking, E. Graff, A. Popescu, J. Orlow. W3C</dd>
<dt id="TypedArray">Typed Array Specification</dt>
- <dd><cite><a href="http://www.khronos.org/registry/typedarray/specs/latest/">Typed Array Specification, Editor's Draft</a></cite>, D. Herman, K. Russell. W3C</dd>
+ <dd><cite><a href="http://www.khronos.org/registry/typedarray/specs/latest/">Typed Array Specification, Editor's Draft</a></cite>, D. Herman, K. Russell. Khronos</dd>
<dt id="TLS">TLS</dt>
<dd><cite><a href="http://tools.ietf.org/html/rfc5246">The Transport Layer Security (TLS) Protocol</a></cite>, T. Dierks, E. Rescorla. W3C</dd>
<dt id="OTR">OTR</dt>