- From: Adam Barth <w3c@adambarth.com>
- Date: Thu, 2 Jun 2011 18:57:11 -0700
- To: David Dahl <ddahl@mozilla.com>
- Cc: public-webapps@w3.org
On Thu, Jun 2, 2011 at 4:46 PM, David Dahl <ddahl@mozilla.com> wrote:
> ----- Original Message -----
> From: "Adam Barth" <w3c@adambarth.com>
> To: "David Dahl" <ddahl@mozilla.com>
> Cc: public-webapps@w3.org
> Sent: Thursday, June 2, 2011 6:19:24 PM
> Subject: Re: Request for feedback: DOMCrypt API proposal
>
>> Why only SHA256? Presumably sha1 and md5 are worth exposing as well.
> Also, pk and sym appear to be algorithm agonistic but hash isn't. In
> addition to hashing, it would be valuable to expose HMAC modes of the
> hash functions.
>
> hash should probably have SHA512 as well, also, I just added an hmac API to the spec.
Really, the API should be algorithm agnostic. We can discuss
separately which algorithms to provide.
>> In the pk API, there doesn't seem to be any way to install a
> public/private keypair from another location (e.g., the network).
>
> No, there is not. Can you suggest what that API would look like? Importing keys should be allowed.
Something like
crypto.pk.importKey(keyBlob)
where keyBlob is something like a string containing the keypair in
something like PEM format.
>> Also, the encrypt and decrypt functions don't let me specify which
> public key I want to use. Consider introducing a keyID concept to let
> me refer to keypairs.
>
> Hmmm, I updated the wiki today as I forgot to include the pubKey on encrypt(). There should be a setter and getter for specifying the keypair to use.
Decrypt needs to take a keypair too (or at least a keyid). As the
caller of the API, you want control over which of your secrets are
used to decrypt the message! Otherwise, you can get it big trouble if
you accidentally decrypt with a powerful key.
>> What is a cipherAddressbook ?
>
> It is an object literal that you store discovered public keys in - which are referred to as "addressbook entries". The Addressbook bits of this API will have to wait for their own spec I think. i was trying to allow for key discovery and storage in the simplest way possible: a custom tag or meta tag is published on your blog and your contacts are alerted by the browser during a visit to the page. The user can then store that 'addressbook entry' (or key) for later use.
Oh man. I'd remove this from the spec. That's a whole other can of
worms. This API should just be the nuts and bolts of the crypto.
>> When I use generateKeypair, how long dose the keypair persist? Is are
> their privacy implications?
> There is nothing in the spec right now. I should probably use a standard cert type that declares validity dates.
This is a very important question. Also, what sites are allowed to
use the generated keypair? One hopes just the origin that generated
it. You could also ask for something tighter so that some random XSS
in one page won't completely compromise all my keys.
You really need to spell all this stuff out in the spec. What you
haven now just completely lacks any details about what these functions
actually do.
>> Finally, this all should be on the crypto object, not on a new cipher object.
>
> More and more people are saying that.
Maybe you should listen to them?
On Thu, Jun 2, 2011 at 4:47 PM, David Dahl <ddahl@mozilla.com> wrote:
>> This spec is also incredibly vague:
>>
>> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
>
>> There's no description of what these functions do. There's no way
> this spec can be used to create a second interoperable implementation.
>
> I really need to change the format to WebIDL or something along those lines.
You should do that, of course, but that's just the first step. You
need to actually explain what these functions do in a level of detail
such that someone else could implement them in exactly the same way as
you have without looking at your implementation. That's what it means
to be an standard for the open web.
Adam
> On Wed, Jun 1, 2011 at 3:54 PM, David Dahl <ddahl@mozilla.com> wrote:
>> Hello public-webapps members,
>>
>> (I wanted to post this proposed draft spec for the DOMCrypt API ( https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest ) to this list - if there is a more fitting mailing list, please let me know)
>>
>> I recently posted this draft spec for a crypto API for browsers to the whatwg (see: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031741.html) and wanted to get feedback from W3C as well.
>>
>> Privacy and user control on the web is of utter importance. Tracking, unauthorized user data aggregation and personal information breaches are becoming so commonplace you see a new headline almost daily. (It seems).
>>
>> We need crypto APIs in browsers to allow developers to create more secure communications tools and web applications that don’t have to implicitly trust the server, among other use cases.
>>
>> The DOMCrypt API is a good start, and more feedback and discussion will really help round out how all of this should work – as well as how it can work in any browser that will support such an API.
>>
>> This API will provide each web browser window with a ‘cipher’ property[1] that facilitates:
>>
>> asymmetric encryption key pair generation
>> public key encryption
>> public key decryption
>> symmetric encryption
>> signature generation
>> signature verification
>> hashing
>> easy public key discovery via meta tags or an ‘addressbookentry’ tag
>>
>> [1] There is a bit of discussion around adding this API to window.navigator or consolidation within window.crypto
>>
>> I have created a Firefox extension that implements most of the above, and am working on an experimental patch that integrates this API into Firefox.
>>
>> 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
>>
>> Firefox "feature wiki page": https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI
>>
>> You can test the API by installing the extension hosted at domcrypt.org, and going to http://domcrypt.org
>>
>> A recent blog post updating all of this is posted here: http://monocleglobe..wordpress.com/2011/06/01/domcrypt-update-2011-06-01/
>>
>> The API:
>>
>> window.cipher = {
>> // Public Key API
>> pk: {
>> set algorithm(algorithm){ },
>> get algorithm(){ },
>>
>> // Generate a keypair and then execute the callback function
>> generateKeypair: function ( function callback( aPublicKey ) { } ) { },
>>
>> // encrypt a plainText
>> encrypt: function ( plainText, function callback (cipherMessageObject) ) { } ) { },
>>
>> // decrypt a cipherMessage
>> decrypt: function ( cipherMessageObject, function callback ( plainText ) { } ) { },
>>
>> // sign a message
>> sign: function ( plainText, function callback ( signature ) { } ) { },
>>
>> // verify a signature
>> verify: function ( signature, plainText, function callback ( boolean ) { } ) { },
>>
>> // get the JSON cipherAddressbook
>> get addressbook() {},
>>
>> // make changes to the addressbook
>> saveAddressbook: function (JSONObject, function callback ( addresssbook ) { }) { }
>> },
>>
>> // Symmetric Crypto API
>> sym: {
>> get algorithm(),
>> set algorithm(algorithm),
>>
>> // create a new symmetric key
>> generateKey: function (function callback ( key ){ }) { },
>>
>> // encrypt some data
>> encrypt: function (plainText, key, function callback( cipherText ){ }) { },
>>
>> // decrypt some data
>> decrypt: function (cipherText, key, function callback( plainText ) { }) { },
>> },
>>
>> // hashing
>> hash: {
>> SHA256: function (function callback (hash){}) { }
>> }
>> }
>>
>> Your feedback and criticism will be invaluable.
>>
>> Best regards,
>>
>> David Dahl
>>
>> Firefox Engineer, Mozilla Corp.
>>
>>
>>
>
Received on Friday, 3 June 2011 01:58:11 UTC