Re: [whatwg] window.cipher HTML crypto API draft spec

[Henri Sivonen]

On Tue, 2011-05-24 at 07:48 -0700, David Dahl wrote:
  Consider for example a DropBox-style service that has a browser-based UI
   but that has a design where content is encrypted on the client-side so
   that the service provider is unable to decrypt the data. In this case,
   it would make sense to be able to implement a file download by having a
   plain a href to an excrypted file and have the browser automatically
   decrypt it. Likewise, a service that allows the transmission of
   encrypted images should be implementable by having img src point
   directly to an encrypted file.
 
 I think someone was asking about that kind of functionality during my 
 presentation at Mozilla. Again, this would be a pretty advanced complement to 
 this API - I would love to see something like that spec'd and implemented as 
 well.

My main worry is that if the two ways of doing crypto don't appear at
the same time for Web authors to use, the Web will shift in an
unfortunately hashbangy direction.

  I suggest adding a Content-Encoding type that tells the HTTP stack that
   the payload of a HTTP response is encrypted and needs to be decrypted
   using a key previously initialized using the JS API.
 
 cool. I'll look into that.

Thanks.

  On the other hand, it seems that letting Web apps generate per-user key
   pairs and letting Web apps discover if the user possesses the private
   key that decrypts a particular message is a privacy problem. Someone who
   wishes to surveil Web users could use private keys as supercookies,
   since the generated private key is most probably going to be unique to
   user.
 
 Currently, my implementation requires the enduser to open a file from the 
 file system in order to view the contents of the private key. It is only 
 accessible to privileged code - content has no access to it whatsoever.

I didn't expect content to have access to the key bits per se. I
expected Web content-provided JS to be able to encrypt and decrypt stuff
with a key it has asked the browser to generate (if the user has
authorized the origin to use the crypto API). The ability to decrypt or
encrypt a message with a particular private key is proof of possession
of that key, so users in possession of a particular key could be
tracked.

This could be mitigated by granting the crypto permissions to a pair of
origins: the origin of the top level frame combined with the origin that
wants to access the API. This way iframed Web bugs could track the user
across sites after having once obtained a crypto permission for their
origin.

See http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-24.pdf

  Currently, it is unfortunate that choosing to use a webmail client
   effectively prevents a person from using encrypted email. To allow
   people to use end-to-end encrypted email with webmail apps, it would be
   useful to support OpenPGP as an encryption format. (Obviously, a
   malicious webmail app could capture the decrypted messages on the
   browser and send them back to the server, but when the webmail app
   itself doesn't contain code like that, putting the decryption in the
   browser rather than putting it on the server would still probably be
   more subpoena-resistant and resistant against casual snooping by bored
   administrators.)
 
 I think with an API like this we might see a whole new breed of 
 communications applications that can supplant email and webmail entirely. 

Maybe. But Google Wave flopped and email is still here. I think it would
be good to design for the ability to plug into email's network effects
instead of counting on a new breed of communication making email
irrelevant.

  The public key discovery section shows a /meta end tag. I hope this is
  just a plain error and having content in a meta element isn't part of
  any design.
 
 The tag is unimportant as well - can you explain why you hope this wil not 
 use a meta tag?

A meta tag can be used if there's no need for the meta element to have
child nodes. You can't make a meta element have child nodes or an end
tag.

  I could just as easily use addressbookentry

You can't introduce an addressbookentry element as a child of the head
element. The result would not degrade gracefully.

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: [whatwg] window.cipher HTML crypto API draft spec

[イアンフェッティ]

I personally find this to be a very interesting and potentially useful
proposals. One of the problems that we / the web face is a legal requirement
faced by many Asian banks (esp. Korea) to digitally sign all transactions.
To meet this requirement, they use ActiveX controls, as the platform doesn't
really give them the primitives they need. This seems like it should give
them what they need, but I would be very interested in knowing whether
there's more that would be needed or whether this would actually suffice.

It would be good if we can figure out whether this is sufficient for e.g.
Korean banking requirements, and if not, what else would be necessary. Does
anyone have contacts with the relevant industry groups?

-Ian

On Fri, May 20, 2011 at 8:04 AM, David Dahl dd...@mozilla.com wrote:

 Hello WHATWG members,

 With user control and privacy in mind, I have created a spec and an
 implementation for an easy to use cryptography API called DOMCrypt. This API
 will provide each web browser window with a 'cipher' property that
 facilitates:

 * asymmetric encryption key pair generation
 * public key encryption
 * decryption
 * signature generation
 * signature verification
 * hashing
 * easy public key discovery via meta tags

 I have created a Firefox extension that implements all of the above, and am
 working on an experimental patch that integrates this API into Firefox.

 The draft spec is here:
 https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest

 The project originated in an extension I wrote, the home page is here:
 http://domcrypt.org

 The source code for the extension is here:
 https://github.com/daviddahl/domcrypt

 The Mozilla bugs are here:
 https://bugzilla.mozilla.org/show_bug.cgi?id=649154
 https://bugzilla.mozilla.org/show_bug.cgi?id=657432

 You can test the API by installing the extension hosted at domcrypt.organd
 addons.mozilla.org, and going to http://domcrypt.org

 Best Regards,

 David Dahl

 Firefox Engineer, Mozilla Corp.

Re: [whatwg] window.cipher HTML crypto API draft spec

[Nicholas Zakas]

I'm excited to see this get some steam behind it, though I'd echo what some 
others have said about this being very targeted at the address book use case. 
The use case I'm more interested in is a bit simpler: I want to encrypt data 
before saving to localStorage. The key may be one that exists solely on the 
server.

IMHO, this is an important use case and potentially more common. I'd really 
like for any encryption API to enable this use case easily, and I'm having a 
hard time figuring if it's possible with this API. Can you share your thoughts 
on this (maybe some pseudo-code)?
 
-Nicholas

-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] 
On Behalf Of David Dahl
Sent: Tuesday, May 24, 2011 7:48 AM
To: Henri Sivonen
Cc: whatwg@lists.whatwg.org
Subject: Re: [whatwg] window.cipher HTML crypto API draft spec

- Original Message -
From: Henri Sivonen hsivo...@iki.fi
To: David Dahl dd...@mozilla.com
Cc: whatwg@lists.whatwg.org
Sent: Tuesday, May 24, 2011 2:25:53 AM
Subject: Re: [whatwg] window.cipher HTML crypto API draft spec

 It seems unfortunate that crypto is only available when a JavaScript
  program explicitly drives encryption. This means that in order to use
  crypto, the Web app has to be written in such a way that all its
  resource handling is programmed in JavaScript instead of using
  traditional browser-handled resource retrievals.

I imagine using resource retrieval would be the way to handle larger binary 
data decryption, and would be an amazing counterpart to this API - it also 
seems like a much bigger project to undertake. The emphasis on DOMCrypt is 
mainly on giving content developers a way to write privacy-enhanced web apps.

 Consider for example a DropBox-style service that has a browser-based UI
  but that has a design where content is encrypted on the client-side so
  that the service provider is unable to decrypt the data. In this case,
  it would make sense to be able to implement a file download by having a
  plain a href to an excrypted file and have the browser automatically
  decrypt it. Likewise, a service that allows the transmission of
  encrypted images should be implementable by having img src point
  directly to an encrypted file.

I think someone was asking about that kind of functionality during my 
presentation at Mozilla. Again, this would be a pretty advanced complement to 
this API - I would love to see something like that spec'd and implemented as 
well.

 I suggest adding a Content-Encoding type that tells the HTTP stack that
  the payload of a HTTP response is encrypted and needs to be decrypted
  using a key previously initialized using the JS API.

cool. I'll look into that.

- -

 On the other hand, it seems that letting Web apps generate per-user key
  pairs and letting Web apps discover if the user possesses the private
  key that decrypts a particular message is a privacy problem. Someone who
  wishes to surveil Web users could use private keys as supercookies,
  since the generated private key is most probably going to be unique to
  user.

Currently, my implementation requires the enduser to open a file from the file 
system in order to view the contents of the private key. It is only accessible 
to privileged code - content has no access to it whatsoever.

 OTOH, wiping keys along with cookies could lead to accidents.
 Is there a plan on how this will integrate into various private data
  deletion UIs in such a way that users have the option to delete keys but
  understand the implications and don't delete them accidentally?

Not yet. There no doubt will have to be a UI that helps users understand the 
ramifications of deleting keys, etc.

 Are all the methods that take a success callback meant to pop up a
  geolocation-style asynchronous authorization UI until the user
  perma-authorizes a site to use crypto?

It is not implemented yet, but yes, that would be the plan.
- -

 Is the plan to use Firefox Sync to sync the user's private keys across
  multiple browser instances so that the user doesn't need to manually
  transfer keys in the usual case?

I do think so, however, there are those who would caution against the private 
key ever going over the wire. I think with Sync, it would be safe.

- -

 Currently, it is unfortunate that choosing to use a webmail client
  effectively prevents a person from using encrypted email. To allow
  people to use end-to-end encrypted email with webmail apps, it would be
  useful to support OpenPGP as an encryption format. (Obviously, a
  malicious webmail app could capture the decrypted messages on the
  browser and send them back to the server, but when the webmail app
  itself doesn't contain code like that, putting the decryption in the
  browser rather than putting it on the server would still probably be
  more subpoena-resistant and resistant against casual snooping by bored
  administrators.)

I think with an API like this we might see

Re: [whatwg] window.cipher HTML crypto API draft spec

[David Dahl]

Nicholas:

Sure thing. The symmetric API would look something like this: 

cipher.sym.generateKey(function callback(aKey){})
cipher.sym.encrypt(plainText, key, function callback(cipherText){})
cipher.sym.decrypt(cipherText, key, function callback(plainText){})

--- sample code ---
function createKey() {
  cipher.sym.generateKey(function (aKey){
XHR.post(/save-key/, {key: aKey}, function (result){
  if (result)
alert(Success: Your key was saved.);
});
  });
}

function saveRecord(aRecord, aKey) {
  cipher.sym.encrypt(aRecord, aKey, function (aCipherText) {
localStorage.setItem(foo, aCipherText);
  });
}

function readRecord(aID, aKey) {
  var cipherRecord = localStorage.getItem(aID);
  cipher.sym.decrypt(cipherRecord, aKey, function (plainText){
alert(plainText);
  });
}

The web app would have your browser create a key, send it to the server via 
xhr, etc, then you can use encrypt() and decrypt() to secure your localStorage 
data.

I will add the symmetric API bits to the spec. The implementation is nearly 
already done as all of the public key encryption already uses symmetric crypto 
behind the scenes. I will also add this to my implementation for 
experimentation.

Regards,

David

- Original Message -
From: Nicholas Zakas nza...@yahoo-inc.com
To: David Dahl dd...@mozilla.com, Henri Sivonen hsivo...@iki.fi
Cc: whatwg@lists.whatwg.org
Sent: Tuesday, May 24, 2011 12:04:42 PM
Subject: RE: [whatwg] window.cipher HTML crypto API draft spec

I'm excited to see this get some steam behind it, though I'd echo what some 
others have said about this being very targeted at the address book use case. 
The use case I'm more interested in is a bit simpler: I want to encrypt data 
before saving to localStorage. The key may be one that exists solely on the 
server.

IMHO, this is an important use case and potentially more common. I'd really 
like for any encryption API to enable this use case easily, and I'm having a 
hard time figuring if it's possible with this API. Can you share your thoughts 
on this (maybe some pseudo-code)?
 
-Nicholas

-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] 
On Behalf Of David Dahl
Sent: Tuesday, May 24, 2011 7:48 AM
To: Henri Sivonen
Cc: whatwg@lists.whatwg.org
Subject: Re: [whatwg] window.cipher HTML crypto API draft spec

- Original Message -
From: Henri Sivonen hsivo...@iki.fi
To: David Dahl dd...@mozilla.com
Cc: whatwg@lists.whatwg.org
Sent: Tuesday, May 24, 2011 2:25:53 AM
Subject: Re: [whatwg] window.cipher HTML crypto API draft spec

 It seems unfortunate that crypto is only available when a JavaScript
  program explicitly drives encryption. This means that in order to use
  crypto, the Web app has to be written in such a way that all its
  resource handling is programmed in JavaScript instead of using
  traditional browser-handled resource retrievals.

I imagine using resource retrieval would be the way to handle larger binary 
data decryption, and would be an amazing counterpart to this API - it also 
seems like a much bigger project to undertake. The emphasis on DOMCrypt is 
mainly on giving content developers a way to write privacy-enhanced web apps.

 Consider for example a DropBox-style service that has a browser-based UI
  but that has a design where content is encrypted on the client-side so
  that the service provider is unable to decrypt the data. In this case,
  it would make sense to be able to implement a file download by having a
  plain a href to an excrypted file and have the browser automatically
  decrypt it. Likewise, a service that allows the transmission of
  encrypted images should be implementable by having img src point
  directly to an encrypted file.

I think someone was asking about that kind of functionality during my 
presentation at Mozilla. Again, this would be a pretty advanced complement to 
this API - I would love to see something like that spec'd and implemented as 
well.

 I suggest adding a Content-Encoding type that tells the HTTP stack that
  the payload of a HTTP response is encrypted and needs to be decrypted
  using a key previously initialized using the JS API.

cool. I'll look into that.

- -

 On the other hand, it seems that letting Web apps generate per-user key
  pairs and letting Web apps discover if the user possesses the private
  key that decrypts a particular message is a privacy problem. Someone who
  wishes to surveil Web users could use private keys as supercookies,
  since the generated private key is most probably going to be unique to
  user.

Currently, my implementation requires the enduser to open a file from the file 
system in order to view the contents of the private key. It is only accessible 
to privileged code - content has no access to it whatsoever.

 OTOH, wiping keys along with cookies could lead to accidents.
 Is there a plan on how this will integrate into various private data
  deletion UIs in such a way

Re: [whatwg] window.cipher HTML crypto API draft spec

[Nicholas Zakas]

Why do you assume I want to access the data from localStorage only while 
offline? This use case is for an online data cache.

If I wanted to access the data offline as well, I’d probably still encrypt it 
so that it’s not in plain text on disk.

-Nicholas


From: Ian Fette (イアンフェッティ) [mailto:ife...@google.com]
Sent: Tuesday, May 24, 2011 10:16 AM
To: Nicholas Zakas
Cc: David Dahl; Henri Sivonen; whatwg@lists.whatwg.org
Subject: Re: [whatwg] window.cipher HTML crypto API draft spec

Well, presumably you would be using LocalStorage because you want to use the 
data offline. So, if you're offline, you need the decryption key to be 
available offline, which means either the user has a separate device with the 
key (e.g. a CAC card, not really practical for average users) or the key / 
whatever is needed to decrypt is stored somewhere on the device, at which point 
what's the point of encrypting it?
On Tue, May 24, 2011 at 10:04 AM, Nicholas Zakas 
nza...@yahoo-inc.commailto:nza...@yahoo-inc.com wrote:
I'm excited to see this get some steam behind it, though I'd echo what some 
others have said about this being very targeted at the address book use case. 
The use case I'm more interested in is a bit simpler: I want to encrypt data 
before saving to localStorage. The key may be one that exists solely on the 
server.

IMHO, this is an important use case and potentially more common. I'd really 
like for any encryption API to enable this use case easily, and I'm having a 
hard time figuring if it's possible with this API. Can you share your thoughts 
on this (maybe some pseudo-code)?

-Nicholas

-Original Message-
From: whatwg-boun...@lists.whatwg.orgmailto:whatwg-boun...@lists.whatwg.org 
[mailto:whatwg-boun...@lists.whatwg.orgmailto:whatwg-boun...@lists.whatwg.org]
 On Behalf Of David Dahl
Sent: Tuesday, May 24, 2011 7:48 AM
To: Henri Sivonen
Cc: whatwg@lists.whatwg.orgmailto:whatwg@lists.whatwg.org
Subject: Re: [whatwg] window.cipher HTML crypto API draft spec

- Original Message -
From: Henri Sivonen hsivo...@iki.fimailto:hsivo...@iki.fi
To: David Dahl dd...@mozilla.commailto:dd...@mozilla.com
Cc: whatwg@lists.whatwg.orgmailto:whatwg@lists.whatwg.org
Sent: Tuesday, May 24, 2011 2:25:53 AM
Subject: Re: [whatwg] window.cipher HTML crypto API draft spec

 It seems unfortunate that crypto is only available when a JavaScript
 program explicitly drives encryption. This means that in order to use
 crypto, the Web app has to be written in such a way that all its
 resource handling is programmed in JavaScript instead of using
 traditional browser-handled resource retrievals.

I imagine using resource retrieval would be the way to handle larger binary 
data decryption, and would be an amazing counterpart to this API - it also 
seems like a much bigger project to undertake. The emphasis on DOMCrypt is 
mainly on giving content developers a way to write privacy-enhanced web apps.

 Consider for example a DropBox-style service that has a browser-based UI
 but that has a design where content is encrypted on the client-side so
 that the service provider is unable to decrypt the data. In this case,
 it would make sense to be able to implement a file download by having a
 plain a href to an excrypted file and have the browser automatically
 decrypt it. Likewise, a service that allows the transmission of
 encrypted images should be implementable by having img src point
 directly to an encrypted file.

I think someone was asking about that kind of functionality during my 
presentation at Mozilla. Again, this would be a pretty advanced complement to 
this API - I would love to see something like that spec'd and implemented as 
well.

 I suggest adding a Content-Encoding type that tells the HTTP stack that
 the payload of a HTTP response is encrypted and needs to be decrypted
 using a key previously initialized using the JS API.

cool. I'll look into that.

- -

 On the other hand, it seems that letting Web apps generate per-user key
 pairs and letting Web apps discover if the user possesses the private
 key that decrypts a particular message is a privacy problem. Someone who
 wishes to surveil Web users could use private keys as supercookies,
 since the generated private key is most probably going to be unique to
 user.

Currently, my implementation requires the enduser to open a file from the file 
system in order to view the contents of the private key. It is only accessible 
to privileged code - content has no access to it whatsoever.

 OTOH, wiping keys along with cookies could lead to accidents.
 Is there a plan on how this will integrate into various private data
 deletion UIs in such a way that users have the option to delete keys but
 understand the implications and don't delete them accidentally?

Not yet. There no doubt will have to be a UI that helps users understand the 
ramifications of deleting keys, etc.

 Are all the methods that take a success callback meant to pop

Re: [whatwg] window.cipher HTML crypto API draft spec

[David Dahl]

Another way to do it would be to keep the sym key in localStorage but wrap it 
with your private key, requiring a passphrase prompt to use it for the session.

Cheers,

David

- Original Message -
From: Ian Fette (イアンフェッティ) ife...@google.com
To: Nicholas Zakas nza...@yahoo-inc.com
Cc: David Dahl dd...@mozilla.com, Henri Sivonen hsivo...@iki.fi, 
whatwg@lists.whatwg.org
Sent: Tuesday, May 24, 2011 12:16:09 PM
Subject: Re: [whatwg] window.cipher HTML crypto API draft spec

Well, presumably you would be using LocalStorage because you want to use the
data offline. So, if you're offline, you need the decryption key to be
available offline, which means either the user has a separate device with
the key (e.g. a CAC card, not really practical for average users) or the key
/ whatever is needed to decrypt is stored somewhere on the device, at which
point what's the point of encrypting it?

On Tue, May 24, 2011 at 10:04 AM, Nicholas Zakas nza...@yahoo-inc.comwrote:

 I'm excited to see this get some steam behind it, though I'd echo what some
 others have said about this being very targeted at the address book use
 case. The use case I'm more interested in is a bit simpler: I want to
 encrypt data before saving to localStorage. The key may be one that exists
 solely on the server.

 IMHO, this is an important use case and potentially more common. I'd really
 like for any encryption API to enable this use case easily, and I'm having a
 hard time figuring if it's possible with this API. Can you share your
 thoughts on this (maybe some pseudo-code)?

 -Nicholas

 -Original Message-
 From: whatwg-boun...@lists.whatwg.org [mailto:
 whatwg-boun...@lists.whatwg.org] On Behalf Of David Dahl
 Sent: Tuesday, May 24, 2011 7:48 AM
 To: Henri Sivonen
 Cc: whatwg@lists.whatwg.org
 Subject: Re: [whatwg] window.cipher HTML crypto API draft spec

 - Original Message -
 From: Henri Sivonen hsivo...@iki.fi
 To: David Dahl dd...@mozilla.com
 Cc: whatwg@lists.whatwg.org
 Sent: Tuesday, May 24, 2011 2:25:53 AM
 Subject: Re: [whatwg] window.cipher HTML crypto API draft spec

  It seems unfortunate that crypto is only available when a JavaScript
  program explicitly drives encryption. This means that in order to use
  crypto, the Web app has to be written in such a way that all its
  resource handling is programmed in JavaScript instead of using
  traditional browser-handled resource retrievals.

 I imagine using resource retrieval would be the way to handle larger binary
 data decryption, and would be an amazing counterpart to this API - it also
 seems like a much bigger project to undertake. The emphasis on DOMCrypt is
 mainly on giving content developers a way to write privacy-enhanced web
 apps.

  Consider for example a DropBox-style service that has a browser-based UI
  but that has a design where content is encrypted on the client-side so
  that the service provider is unable to decrypt the data. In this case,
  it would make sense to be able to implement a file download by having a
  plain a href to an excrypted file and have the browser automatically
  decrypt it. Likewise, a service that allows the transmission of
  encrypted images should be implementable by having img src point
  directly to an encrypted file.

 I think someone was asking about that kind of functionality during my
 presentation at Mozilla. Again, this would be a pretty advanced complement
 to this API - I would love to see something like that spec'd and implemented
 as well.

  I suggest adding a Content-Encoding type that tells the HTTP stack that
  the payload of a HTTP response is encrypted and needs to be decrypted
  using a key previously initialized using the JS API.

 cool. I'll look into that.

 - -

  On the other hand, it seems that letting Web apps generate per-user key
  pairs and letting Web apps discover if the user possesses the private
  key that decrypts a particular message is a privacy problem. Someone who
  wishes to surveil Web users could use private keys as supercookies,
  since the generated private key is most probably going to be unique to
  user.

 Currently, my implementation requires the enduser to open a file from the
 file system in order to view the contents of the private key. It is only
 accessible to privileged code - content has no access to it whatsoever.

  OTOH, wiping keys along with cookies could lead to accidents.
  Is there a plan on how this will integrate into various private data
  deletion UIs in such a way that users have the option to delete keys but
  understand the implications and don't delete them accidentally?

 Not yet. There no doubt will have to be a UI that helps users understand
 the ramifications of deleting keys, etc.

  Are all the methods that take a success callback meant to pop up a
  geolocation-style asynchronous authorization UI until the user
  perma-authorizes a site to use crypto?

 It is not implemented yet, but yes, that would be the plan.
 - -

  Is the plan to use

Re: [whatwg] window.cipher HTML crypto API draft spec

[Nicholas Zakas]

Very cool, thanks!

Followup question: is aKey in your example a string or a data structure? The 
reason I ask is because I'd love to generate the key on the server and then 
pass it back to the client for use. When I previously did some thinking about 
this, I was thinking of the key as a base64-encoded value, so just curious what 
you're using.

Thanks again,
Nicholas

-Original Message-
From: David Dahl [mailto:dd...@mozilla.com] 
Sent: Tuesday, May 24, 2011 10:28 AM
To: Nicholas Zakas
Cc: whatwg@lists.whatwg.org; Henri Sivonen
Subject: Re: [whatwg] window.cipher HTML crypto API draft spec

Nicholas:

Sure thing. The symmetric API would look something like this: 

cipher.sym.generateKey(function callback(aKey){})
cipher.sym.encrypt(plainText, key, function callback(cipherText){})
cipher.sym.decrypt(cipherText, key, function callback(plainText){})

--- sample code ---
function createKey() {
  cipher.sym.generateKey(function (aKey){
XHR.post(/save-key/, {key: aKey}, function (result){
  if (result)
alert(Success: Your key was saved.);
});
  });
}

function saveRecord(aRecord, aKey) {
  cipher.sym.encrypt(aRecord, aKey, function (aCipherText) {
localStorage.setItem(foo, aCipherText);
  });
}

function readRecord(aID, aKey) {
  var cipherRecord = localStorage.getItem(aID);
  cipher.sym.decrypt(cipherRecord, aKey, function (plainText){
alert(plainText);
  });
}

The web app would have your browser create a key, send it to the server via 
xhr, etc, then you can use encrypt() and decrypt() to secure your localStorage 
data.

I will add the symmetric API bits to the spec. The implementation is nearly 
already done as all of the public key encryption already uses symmetric crypto 
behind the scenes. I will also add this to my implementation for 
experimentation.

Regards,

David

- Original Message -
From: Nicholas Zakas nza...@yahoo-inc.com
To: David Dahl dd...@mozilla.com, Henri Sivonen hsivo...@iki.fi
Cc: whatwg@lists.whatwg.org
Sent: Tuesday, May 24, 2011 12:04:42 PM
Subject: RE: [whatwg] window.cipher HTML crypto API draft spec

I'm excited to see this get some steam behind it, though I'd echo what some 
others have said about this being very targeted at the address book use case. 
The use case I'm more interested in is a bit simpler: I want to encrypt data 
before saving to localStorage. The key may be one that exists solely on the 
server.

IMHO, this is an important use case and potentially more common. I'd really 
like for any encryption API to enable this use case easily, and I'm having a 
hard time figuring if it's possible with this API. Can you share your thoughts 
on this (maybe some pseudo-code)?
 
-Nicholas

-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] 
On Behalf Of David Dahl
Sent: Tuesday, May 24, 2011 7:48 AM
To: Henri Sivonen
Cc: whatwg@lists.whatwg.org
Subject: Re: [whatwg] window.cipher HTML crypto API draft spec

- Original Message -
From: Henri Sivonen hsivo...@iki.fi
To: David Dahl dd...@mozilla.com
Cc: whatwg@lists.whatwg.org
Sent: Tuesday, May 24, 2011 2:25:53 AM
Subject: Re: [whatwg] window.cipher HTML crypto API draft spec

 It seems unfortunate that crypto is only available when a JavaScript
  program explicitly drives encryption. This means that in order to use
  crypto, the Web app has to be written in such a way that all its
  resource handling is programmed in JavaScript instead of using
  traditional browser-handled resource retrievals.

I imagine using resource retrieval would be the way to handle larger binary 
data decryption, and would be an amazing counterpart to this API - it also 
seems like a much bigger project to undertake. The emphasis on DOMCrypt is 
mainly on giving content developers a way to write privacy-enhanced web apps.

 Consider for example a DropBox-style service that has a browser-based UI
  but that has a design where content is encrypted on the client-side so
  that the service provider is unable to decrypt the data. In this case,
  it would make sense to be able to implement a file download by having a
  plain a href to an excrypted file and have the browser automatically
  decrypt it. Likewise, a service that allows the transmission of
  encrypted images should be implementable by having img src point
  directly to an encrypted file.

I think someone was asking about that kind of functionality during my 
presentation at Mozilla. Again, this would be a pretty advanced complement to 
this API - I would love to see something like that spec'd and implemented as 
well.

 I suggest adding a Content-Encoding type that tells the HTTP stack that
  the payload of a HTTP response is encrypted and needs to be decrypted
  using a key previously initialized using the JS API.

cool. I'll look into that.

- -

 On the other hand, it seems that letting Web apps generate per-user key
  pairs and letting Web apps discover if the user possesses the private

Re: [whatwg] window.cipher HTML crypto API draft spec

[David Dahl]

- Original Message -
From: Jungshik Shin (신정식, 申政湜) jungs...@google.com
To: Ian Fette ife...@google.com
Cc: David Dahl dd...@mozilla.com, WHATWG Proposals 
whatwg@lists.whatwg.org, cha...@gmail.com
Sent: Tuesday, May 24, 2011 2:36:01 PM
Subject: Re: [whatwg] window.cipher HTML crypto API draft spec

Great insight into the situation in Korea, thanks!

 It looks like what David proposed seems to be a good start, but I'm afraid
  it's not sufficient yet to replace various browser-plugins/add-ons used for
  digital sigining and certificate management (as is done in Korea). For
  instance, Channy Yun (who's the leader of Mozilla Koran user group: I'm
  copying to him) has the following proposal.

 http://html5.creation.net/webcrypto-api/

Thank you for the link. I need to read all of these ideas and specs.

 It covers the generation of cert request, cert import, smart card event
  handling (apparently, in China, smartcards are widely used for on-line
  banking) in addition to signing text. 'keygen' (codified in html5) appears
  to cover some of needs for cert request and cert issuance, but does not go
  all the way (to be useful).

yeah, keygen would be so much better as part of an API rather than being part 
of a form, etc. 

 I also wonder what David's proposal has to do with another Mozilla effort in
  the area : https://wiki.mozilla.org/Labs/Secret

The Secret project seems to have fizzled out, never getting past the 
brainstorming phase. That being said a lot of the functionality of my 
implementation stems from the Weave (now Sync) project at Mozilla, which 
presumably may have been some of the underpinnings of the Secret project - at 
least in theory.

Regards,

David

Re: [whatwg] window.cipher HTML crypto API draft spec

[신정식, 申政湜]

Thank you for the reply, David.

It's my mistake to send it without subscribing to the list. To avoid further
splitting the thread, I'm including below my original email here for others
to see (and to be archived).

BTW, while doing so, I'm adding a pointer to a chromium bug with some more
background on PKI and digital signing (in Korea and elsewhere) :
http://crbug.com/73226  (David has already found it and added a comment
there :-)).

Jungshik

2011/5/24 Ian Fette (イアンフェッティ) ife...@google.com

I personally find this to be a very interesting and potentially useful
 proposals. One of the problems that we / the web face is a legal requirement
 faced by many Asian banks (esp. Korea) to digitally sign all transactions.
 To meet this requirement, they use ActiveX controls, as the platform doesn't
 really give them the primitives they need. This seems like it should give
 them what they need, but I would be very interested in knowing whether
 there's more that would be needed or whether this would actually suffice.


The situation in Korea got a bit better recently in the sense that some
banks (or government agencies) now have a Firefox extension (with an xpcom
plugin), an npapi plugin, a Safari extension (on Mac OS only), and a Java
applet in addition to ActiveX controls (I can do online banking on Linux and
Mac ! :-)) . Obviously, this 'proliferation' of browser plugins is far
from ideal and it'd be great if there's a standard set of API to do what
these 'browser plugins' do.



 It would be good if we can figure out whether this is sufficient for e.g.
 Korean banking requirements, and if not, what else would be necessary. Does
 anyone have contacts with the relevant industry groups?


Earlier in the thread, JeffH mentioned the following. The first two threads
in his list  are relevant to on-line banking/e-commerce/government service
access in Korea and elsewhere.

While that's sorta interesting, there's various use cases that've been
mentioned in various places that the above proposed API doesn't necessarily
address..
Web Sigining in Action
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0898.html
Re: Web Sigining in Action
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0953.html
JS crypto? (and ensuing thread)
http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0605.html
Re: Hash functions (and ensuing thread)
http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/1041.html


It looks like what David proposed seems to be a good start, but I'm afraid
it's not sufficient yet to replace various browser-plugins/add-ons used for
digital sigining and certificate management (as is done in Korea). For
instance, Channy Yun (who's the leader of Mozilla Koran user group: I'm
copying to him) has the following proposal.

http://html5.creation.net/webcrypto-api/

It covers the generation of cert request, cert import, smart card event
handling (apparently, in China, smartcards are widely used for on-line
banking) in addition to signing text. 'keygen' (codified in html5) appears
to cover some of needs for cert request and cert issuance, but does not go
all the way (to be useful).

I also wonder what David's proposal has to do with another Mozilla effort in
the area : https://wiki.mozilla.org/Labs/Secret

Jungshik

2011/5/24 David Dahl dd...@mozilla.com


 - Original Message -
 From: Jungshik Shin (신정식, 申政湜) jungs...@google.com
 To: Ian Fette ife...@google.com
 Cc: David Dahl dd...@mozilla.com, WHATWG Proposals 
 whatwg@lists.whatwg.org, cha...@gmail.com
 Sent: Tuesday, May 24, 2011 2:36:01 PM
 Subject: Re: [whatwg] window.cipher HTML crypto API draft spec

 Great insight into the situation in Korea, thanks!

  It looks like what David proposed seems to be a good start, but I'm
 afraid
  it's not sufficient yet to replace various browser-plugins/add-ons used
 for
  digital sigining and certificate management (as is done in Korea). For
  instance, Channy Yun (who's the leader of Mozilla Koran user group: I'm
  copying to him) has the following proposal.

  http://html5.creation.net/webcrypto-api/

 Thank you for the link. I need to read all of these ideas and specs.

  It covers the generation of cert request, cert import, smart card event
  handling (apparently, in China, smartcards are widely used for on-line
  banking) in addition to signing text. 'keygen' (codified in html5) appears
  to cover some of needs for cert request and cert issuance, but does not go
  all the way (to be useful).

 yeah, keygen would be so much better as part of an API rather than being
 part of a form, etc.

  I also wonder what David's proposal has to do with another Mozilla effort
 in
  the area : https://wiki.mozilla.org/Labs/Secret

 The Secret project seems to have fizzled out, never getting past the
 brainstorming phase. That being said a lot of the functionality of my
 implementation stems from the Weave (now Sync) project at Mozilla, which
 presumably may have been some

Re: [whatwg] window.cipher HTML crypto API draft spec

[=JeffH]

David Dahl replied..

 Simon Heckmann si...@simonheckmann.de asked..

 Why does it only handle asymmetric encryption? Something to
 encrypt/decrypt data with e.g. AES would be nice as well!

 I do need to add a symmetric encryption API as well, my current focus has
 been on the exchange of message between web users, but that is only one
 facet of the results of this effort. I should look at the big picture a bit
 and think about what that API should look like.

Various folks have been thinking about the need to leverage platform crypto
functions (rather than implementing crypto in JS libraries) via a 
standardized API for browser-side web app code such that a
swath of use cases is addressed, here's a couple examples of such position 
statements..


  The Need for a Web Security API
  http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_28.pdf

  Wanted: Native JS Encryption
  http://robert.accettura.com/blog/2011/03/03/wanted-native-js-encryption/
  https://mail.mozilla.org/pipermail/es-discuss/2011-March/013144.html

Some have noted that there ought to be a very high level API built on top of
such a substrate that web app developers could use for their more common use
cases. Keyczar is one example of such an API http://www.keyczar.org/, and 
cryptlib is another 
http://www.cryptlib.com/security-software/programming-code-examples.



Adam Barth replied..

 David Dahl said..

 Yes, that is the case, I am using NSS. I imagine other browser vendors
 would also use NSS to implement this.

 It's very unlikely that Microsoft will use NSS to implement this API in IE.

Agreed.  We nominally need an API that can be implemented by interfacing with 
NSS and CAPI (Microsoft Cryptography API) (arguably as well as OpenSSL, GPG, 
OpenPGP, etc).


fyi/fwiw, another thread from earlier this year cross-posted between this list 
and es-disc...@mozilla.org noted that there is some discussion amongst the 
EcmaScript spec folk about defining an a real crypto API..


  [whatwg] Cryptographically strong random numbers  (Mark Miller)
  
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030452.html


=JeffH

Re: [whatwg] window.cipher HTML crypto API draft spec

[Jonas Sicking]

On Mon, May 23, 2011 at 8:14 PM, =JeffH jeff.hod...@kingsmountain.com wrote:
 David Dahl replied..

 Simon Heckmann si...@simonheckmann.de asked..

 Why does it only handle asymmetric encryption? Something to
 encrypt/decrypt data with e.g. AES would be nice as well!

 I do need to add a symmetric encryption API as well, my current focus has
 been on the exchange of message between web users, but that is only one
 facet of the results of this effort. I should look at the big picture a
 bit
 and think about what that API should look like.

 Various folks have been thinking about the need to leverage platform crypto
 functions (rather than implementing crypto in JS libraries) via a
 standardized API for browser-side web app code such that a
 swath of use cases is addressed, here's a couple examples of such position
 statements..

  The Need for a Web Security API
  http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_28.pdf

  Wanted: Native JS Encryption
  http://robert.accettura.com/blog/2011/03/03/wanted-native-js-encryption/
  https://mail.mozilla.org/pipermail/es-discuss/2011-March/013144.html

 Some have noted that there ought to be a very high level API built on top of
 such a substrate that web app developers could use for their more common use
 cases. Keyczar is one example of such an API http://www.keyczar.org/, and
 cryptlib is another
 http://www.cryptlib.com/security-software/programming-code-examples.

Couldn't this high level API be the API that David is proposing? Or
are these threads calling for something even higher level?

 Adam Barth replied..

 David Dahl said..

 Yes, that is the case, I am using NSS. I imagine other browser vendors
 would also use NSS to implement this.

 It's very unlikely that Microsoft will use NSS to implement this API in
 IE.

 Agreed.  We nominally need an API that can be implemented by interfacing
 with NSS and CAPI (Microsoft Cryptography API) (arguably as well as OpenSSL,
 GPG, OpenPGP, etc).

The API David is proposing is looking generic enough to me that it
should be no problem implementing in libraries other than NSS. Do you
see any reason it wouldn't be?

As a separate question, is anyone here familiar enough with keygen to
know if the proposed API could replace keygen?

/ Jonas

Re: [whatwg] window.cipher HTML crypto API draft spec

[Mike Hanson]

The Need for Web Security API paper is a good intro - we'll be discussing it 
in the W3C Identity workshop tomorrow.  I'll make sure this thread makes it 
into the requirements discussion.

In talking with a couple people about it today, it became clear that there at 
least two, maybe three (or more), layers to a browser-level crypto API.

The first level is math: fast, correct, FIPS 140-audited implementations of 
common crypto algorithms.  Parser implementations might go in this bucket as 
well.

The second is authority-granting: allowing web content to access keying 
material that resides outside of the content's usual purview, typically for 
integrity-protecting or authenticating purposes.  This could be as simple as 
key material held outside of the content's access, or as complex as a hardware 
security module.  PKCS11 will come up at some point in this conversation.  
Perhaps hardware randomness is in this bin.

The third sort-of domain, is in level-crossing: think of providing access to 
SSL/TLS keys from content, as in RFC 5705.  There are probably 
authority-granting cases here that I haven't thought of.  This may not be a 
useful distinction.

I suspect that it will be useful to lightly separate the math conversation 
from the authority conversation - they are both interesting but they probably 
involve different people and different concerns.

-Mike


On May 23, 2011, at 9:05 PM, Jonas Sicking wrote:

 On Mon, May 23, 2011 at 8:14 PM, =JeffH jeff.hod...@kingsmountain.com wrote:
 David Dahl replied..
 
 Simon Heckmann si...@simonheckmann.de asked..
 
 Why does it only handle asymmetric encryption? Something to
 encrypt/decrypt data with e.g. AES would be nice as well!
 
 I do need to add a symmetric encryption API as well, my current focus has
 been on the exchange of message between web users, but that is only one
 facet of the results of this effort. I should look at the big picture a
 bit
 and think about what that API should look like.
 
 Various folks have been thinking about the need to leverage platform crypto
 functions (rather than implementing crypto in JS libraries) via a
 standardized API for browser-side web app code such that a
 swath of use cases is addressed, here's a couple examples of such position
 statements..
 
  The Need for a Web Security API
  http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_28.pdf
 
  Wanted: Native JS Encryption
  http://robert.accettura.com/blog/2011/03/03/wanted-native-js-encryption/
  https://mail.mozilla.org/pipermail/es-discuss/2011-March/013144.html
 
 Some have noted that there ought to be a very high level API built on top of
 such a substrate that web app developers could use for their more common use
 cases. Keyczar is one example of such an API http://www.keyczar.org/, and
 cryptlib is another
 http://www.cryptlib.com/security-software/programming-code-examples.
 
 Couldn't this high level API be the API that David is proposing? Or
 are these threads calling for something even higher level?
 
 Adam Barth replied..
 
 David Dahl said..
 
 Yes, that is the case, I am using NSS. I imagine other browser vendors
 would also use NSS to implement this.
 
 It's very unlikely that Microsoft will use NSS to implement this API in
 IE.
 
 Agreed.  We nominally need an API that can be implemented by interfacing
 with NSS and CAPI (Microsoft Cryptography API) (arguably as well as OpenSSL,
 GPG, OpenPGP, etc).
 
 The API David is proposing is looking generic enough to me that it
 should be no problem implementing in libraries other than NSS. Do you
 see any reason it wouldn't be?
 
 As a separate question, is anyone here familiar enough with keygen to
 know if the proposed API could replace keygen?
 
 / Jonas

Re: [whatwg] window.cipher HTML crypto API draft spec

[David Dahl]

The implementation is secondary in this effort. I think I have nailed down an 
elegant API that web developers can understand and easily use without shooting 
themselves and others in the foot.

Regards,

David

- Original Message -
From: =JeffH jeff.hod...@kingsmountain.com
To: whatwg@lists.whatwg.org
Sent: Monday, May 23, 2011 10:14:36 PM
Subject: Re: [whatwg] window.cipher HTML crypto API draft spec

David Dahl replied..
 
  Simon Heckmann si...@simonheckmann.de asked..
 
  Why does it only handle asymmetric encryption? Something to
  encrypt/decrypt data with e.g. AES would be nice as well!
 
  I do need to add a symmetric encryption API as well, my current focus has
  been on the exchange of message between web users, but that is only one
  facet of the results of this effort. I should look at the big picture a bit
  and think about what that API should look like.

Various folks have been thinking about the need to leverage platform crypto
functions (rather than implementing crypto in JS libraries) via a 
standardized API for browser-side web app code such that a
swath of use cases is addressed, here's a couple examples of such position 
statements..

   The Need for a Web Security API
   http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_28.pdf

   Wanted: Native JS Encryption
   http://robert.accettura.com/blog/2011/03/03/wanted-native-js-encryption/
   https://mail.mozilla.org/pipermail/es-discuss/2011-March/013144.html

Some have noted that there ought to be a very high level API built on top of
such a substrate that web app developers could use for their more common use
cases. Keyczar is one example of such an API http://www.keyczar.org/, and 
cryptlib is another 
http://www.cryptlib.com/security-software/programming-code-examples.


Adam Barth replied..
 
  David Dahl said..
 
  Yes, that is the case, I am using NSS. I imagine other browser vendors
  would also use NSS to implement this.
 
  It's very unlikely that Microsoft will use NSS to implement this API in IE.

Agreed.  We nominally need an API that can be implemented by interfacing with 
NSS and CAPI (Microsoft Cryptography API) (arguably as well as OpenSSL, GPG, 
OpenPGP, etc).

fyi/fwiw, another thread from earlier this year cross-posted between this list 
and es-disc...@mozilla.org noted that there is some discussion amongst the 
EcmaScript spec folk about defining an a real crypto API..

   [whatwg] Cryptographically strong random numbers  (Mark Miller)
   
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-February/030452.html


=JeffH

Re: [whatwg] window.cipher HTML crypto API draft spec

[David Dahl]

One thing that is covered in passing in the DOMCrypt spec is having the browser 
ask the user to whitelist pages or domains that can access public keys, key 
generation, addressbook or any other API method or data. I imagine this would 
be implemented much like way geolocation data access is handled. Perhaps I need 
to make it more clear.

Regards,

David

- Original Message -
From: Mike Hanson mhan...@mozilla.com
To: Jonas Sicking jo...@sicking.cc
Cc: whatwg@lists.whatwg.org, =JeffH jeff.hod...@kingsmountain.com
Sent: Monday, May 23, 2011 11:25:39 PM
Subject: Re: [whatwg] window.cipher HTML crypto API draft spec

...

The second is authority-granting: allowing web content to access keying 
material that resides outside of the content's usual purview, typically for 
integrity-protecting or authenticating purposes.  This could be as simple as 
key material held outside of the content's access, or as complex as a hardware 
security module.  PKCS11 will come up at some point in this conversation.  
Perhaps hardware randomness is in this bin.

The third sort-of domain, is in level-crossing: think of providing access to 
SSL/TLS keys from content, as in RFC 5705.  There are probably 
authority-granting cases here that I haven't thought of.  This may not be a 
useful distinction.

I suspect that it will be useful to lightly separate the math conversation 
from the authority conversation - they are both interesting but they probably 
involve different people and different concerns.

-Mike


On May 23, 2011, at 9:05 PM, Jonas Sicking wrote:

 On Mon, May 23, 2011 at 8:14 PM, =JeffH jeff.hod...@kingsmountain.com wrote:
 David Dahl replied..
 
 Simon Heckmann si...@simonheckmann.de asked..
 
 Why does it only handle asymmetric encryption? Something to
 encrypt/decrypt data with e.g. AES would be nice as well!
 
 I do need to add a symmetric encryption API as well, my current focus has
 been on the exchange of message between web users, but that is only one
 facet of the results of this effort. I should look at the big picture a
 bit
 and think about what that API should look like.
 
 Various folks have been thinking about the need to leverage platform crypto
 functions (rather than implementing crypto in JS libraries) via a
 standardized API for browser-side web app code such that a
 swath of use cases is addressed, here's a couple examples of such position
 statements..
 
  The Need for a Web Security API
  http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_28.pdf
 
  Wanted: Native JS Encryption
  http://robert.accettura.com/blog/2011/03/03/wanted-native-js-encryption/
  https://mail.mozilla.org/pipermail/es-discuss/2011-March/013144.html
 
 Some have noted that there ought to be a very high level API built on top of
 such a substrate that web app developers could use for their more common use
 cases. Keyczar is one example of such an API http://www.keyczar.org/, and
 cryptlib is another
 http://www.cryptlib.com/security-software/programming-code-examples.
 
 Couldn't this high level API be the API that David is proposing? Or
 are these threads calling for something even higher level?
 
 Adam Barth replied..
 
 David Dahl said..
 
 Yes, that is the case, I am using NSS. I imagine other browser vendors
 would also use NSS to implement this.
 
 It's very unlikely that Microsoft will use NSS to implement this API in
 IE.
 
 Agreed.  We nominally need an API that can be implemented by interfacing
 with NSS and CAPI (Microsoft Cryptography API) (arguably as well as OpenSSL,
 GPG, OpenPGP, etc).
 
 The API David is proposing is looking generic enough to me that it
 should be no problem implementing in libraries other than NSS. Do you
 see any reason it wouldn't be?
 
 As a separate question, is anyone here familiar enough with keygen to
 know if the proposed API could replace keygen?
 
 / Jonas

Re: [whatwg] window.cipher HTML crypto API draft spec

[Adam Barth]

Why window.cipher and not just window.crypto?

Adam


On Fri, May 20, 2011 at 8:04 AM, David Dahl dd...@mozilla.com wrote:
 Hello WHATWG members,

 With user control and privacy in mind, I have created a spec and an 
 implementation for an easy to use cryptography API called DOMCrypt. This API 
 will provide each web browser window with a 'cipher' property that 
 facilitates:

 * asymmetric encryption key pair generation
 * public key encryption
 * decryption
 * signature generation
 * signature verification
 * hashing
 * easy public key discovery via meta tags

 I have created a Firefox extension that implements all of the above, and am 
 working on an experimental patch that integrates this API into Firefox.

 The draft spec is here: 
 https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest

 The project originated in an extension I wrote, the home page is here: 
 http://domcrypt.org

 The source code for the extension is here: 
 https://github.com/daviddahl/domcrypt

 The Mozilla bugs are here:
 https://bugzilla.mozilla.org/show_bug.cgi?id=649154
 https://bugzilla.mozilla.org/show_bug.cgi?id=657432

 You can test the API by installing the extension hosted at domcrypt.org and 
 addons.mozilla.org, and going to http://domcrypt.org

 Best Regards,

 David Dahl

 Firefox Engineer, Mozilla Corp.

Re: [whatwg] window.cipher HTML crypto API draft spec

[David Levin]

Should it also be available in Web Workers?

On Fri, May 20, 2011 at 11:45 AM, Adam Barth w...@adambarth.com wrote:

 Why window.cipher and not just window.crypto?

 Adam


 On Fri, May 20, 2011 at 8:04 AM, David Dahl dd...@mozilla.com wrote:
  Hello WHATWG members,
 
  With user control and privacy in mind, I have created a spec and an
 implementation for an easy to use cryptography API called DOMCrypt. This API
 will provide each web browser window with a 'cipher' property that
 facilitates:
 
  * asymmetric encryption key pair generation
  * public key encryption
  * decryption
  * signature generation
  * signature verification
  * hashing
  * easy public key discovery via meta tags
 
  I have created a Firefox extension that implements all of the above, and
 am working on an experimental patch that integrates this API into Firefox.
 
  The draft spec is here:
 https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
 
  The project originated in an extension I wrote, the home page is here:
 http://domcrypt.org
 
  The source code for the extension is here:
 https://github.com/daviddahl/domcrypt
 
  The Mozilla bugs are here:
  https://bugzilla.mozilla.org/show_bug.cgi?id=649154
  https://bugzilla.mozilla.org/show_bug.cgi?id=657432
 
  You can test the API by installing the extension hosted at domcrypt.organd
 addons.mozilla.org, and going to http://domcrypt.org
 
  Best Regards,
 
  David Dahl
 
  Firefox Engineer, Mozilla Corp.
 

Re: [whatwg] window.cipher HTML crypto API draft spec

[=JeffH]

 With user control and privacy in mind, I have created a spec and an
 implementation for an easy to use cryptography API called DOMCrypt. This API
 will provide each web browser window with a 'cipher' property that
 facilitates:

 * asymmetric encryption key pair generation
 * public key encryption
 * decryption
 * signature generation
 * signature verification
 * hashing
 * easy public key discovery via meta tags

 I have created a Firefox extension that implements all of the above, and am
 working on an experimental patch that integrates this API into Firefox.

A subtle-but-important aspect to note about the above is that you impl'd it via 
interfacing to the in-browser NSS API rather than (re)coding it in JS.



 The draft spec is here:
 https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest

It's an interesting start, but the methods of the window.cipher property appear 
to be tailored pretty specifically for your addressbook use case..


  https://wiki.mozilla.org/Privacy/Features/mozCipherAddressbook

..which itself describes an implicit key exchange mechanism.


While that's sorta interesting, there's various use cases that've been 
mentioned in various places that the above proposed API doesn't necessarily 
address..


   Web Sigining in Action
   http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0898.html

   Re: Web Sigining in Action
   http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0953.html

   JS crypto?   (and ensuing thread)
   http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0605.html

   Re: Hash functions   (and ensuing thread)
   http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/1041.html


Additionally, key exchange often becomes a tar pit. It'd be great if there were 
functionality in such a JS-accessible API so that one could leverage keying 
material from underlying, e.g. TLS, key exchanges (see RFC 5705, and keying 
material exporter column in 
https://secure.wikimedia.org/wikipedia/en/wiki/Comparison_of_TLS_Implementations#Extensions; 
also NSS'
SSL_PeerCertificate() with which one can get the peer's cert and thus public 
key), rather than invent new ones.


HTH,

=JeffH

Re: [whatwg] window.cipher HTML crypto API draft spec

[David Dahl]

- Original Message -
From: =JeffH jeff.hod...@kingsmountain.com
To: whatwg@lists.whatwg.org

  I have created a Firefox extension that implements all of the above, and am
  working on an experimental patch that integrates this API into Firefox.

 A subtle-but-important aspect to note about the above is that you impl'd it 
 via 
  interfacing to the in-browser NSS API rather than (re)coding it in JS.

Yes, that is the case, I am using NSS. I imagine other browser vendors would 
also use NSS to implement this.

  The draft spec is here:
  https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest

 It's an interesting start, but the methods of the window.cipher property 
 appear 
  to be tailored pretty specifically for your addressbook use case..

   https://wiki.mozilla.org/Privacy/Features/mozCipherAddressbook

 ..which itself describes an implicit key exchange mechanism.
Indeed it does. the first use case I have in mind is pseudo-anonymous 
communication via social networking. Hence the namespacing in the API. Other 
use cases I have not tackled yet are symmetric encryption via a variety of 
algos, etc...

 While that's sorta interesting, there's various use cases that've been 
  mentioned in various places that the above proposed API doesn't necessarily 
  address..

   Web Sigining in Action
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0898.html

   Re: Web Sigining in Action
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0953.html

   JS crypto?  (and ensuing thread)
http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0605.html

   Re: Hash functions  (and ensuing thread)
http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/1041.html

I will have to read these threads and get back to you. I am familiar with some 
of them.


 Additionally, key exchange often becomes a tar pit. It'd be great if there 
 were 
  functionality in such a JS-accessible API so that one could leverage keying 
  material from underlying, e.g. TLS, key exchanges (see RFC 5705, and keying 
  material exporter column in 
  
https://secure.wikimedia.org/wikipedia/en/wiki/Comparison_of_TLS_Implementations#Extensions;
 
  also NSS'
  SSL_PeerCertificate() with which one can get the peer's cert and thus public 
  key), rather than invent new ones.

I am definitely not trying to tackle the great key exchange solution. I was 
thinking about how, on the most basic level you could simply publish your 
addressbook entry for others to collect. A meta tag came to mind as something 
quite simple - the browser just needs a way to prompt the user and save the 
data as JSON. 

Thank you for the feedback, you have provided me with a lot of weekend reading.

Regards,

David

Re: [whatwg] window.cipher HTML crypto API draft spec

[Adam Barth]

On Fri, May 20, 2011 at 2:16 PM, David Dahl dd...@mozilla.com wrote:
 - Original Message -
 From: =JeffH jeff.hod...@kingsmountain.com
 To: whatwg@lists.whatwg.org

   I have created a Firefox extension that implements all of the above, and 
 am
   working on an experimental patch that integrates this API into Firefox.

 A subtle-but-important aspect to note about the above is that you impl'd it 
 via
  interfacing to the in-browser NSS API rather than (re)coding it in JS.

 Yes, that is the case, I am using NSS. I imagine other browser vendors would 
 also use NSS to implement this.

It's very unlikely that Microsoft will use NSS to implement this API in IE.

Adam

Re: [whatwg] window.cipher HTML crypto API draft spec

[Simon Heckmann]

Why does it only handle asymmetric encryption? Something to encrypt/decrypt 
data with e.g. AES would be nice as well!

Kind regards,
Simon Heckmann


Am 20.05.2011 um 20:45 schrieb Adam Barth w...@adambarth.com:

 Why window.cipher and not just window.crypto?
 
 Adam
 
 
 On Fri, May 20, 2011 at 8:04 AM, David Dahl dd...@mozilla.com wrote:
 Hello WHATWG members,
 
 With user control and privacy in mind, I have created a spec and an 
 implementation for an easy to use cryptography API called DOMCrypt. This API 
 will provide each web browser window with a 'cipher' property that 
 facilitates:
 
 * asymmetric encryption key pair generation
 * public key encryption
 * decryption
 * signature generation
 * signature verification
 * hashing
 * easy public key discovery via meta tags
 
 I have created a Firefox extension that implements all of the above, and am 
 working on an experimental patch that integrates this API into Firefox.
 
 The draft spec is here: 
 https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
 
 The project originated in an extension I wrote, the home page is here: 
 http://domcrypt.org
 
 The source code for the extension is here: 
 https://github.com/daviddahl/domcrypt
 
 The Mozilla bugs are here:
 https://bugzilla.mozilla.org/show_bug.cgi?id=649154
 https://bugzilla.mozilla.org/show_bug.cgi?id=657432
 
 You can test the API by installing the extension hosted at domcrypt.org and 
 addons.mozilla.org, and going to http://domcrypt.org
 
 Best Regards,
 
 David Dahl
 
 Firefox Engineer, Mozilla Corp.