----- Original Message ----- From: "Adam Barth" <w...@adambarth.com> To: "David Dahl" <dd...@mozilla.com> Cc: public-webapps@w3.org Sent: Thursday, June 2, 2011 8:57:11 PM Subject: Re: Request for feedback: DOMCrypt API proposal
> Really, the API should be algorithm agnostic. We can discuss separately > which algorithms to provide. So, perhaps adding a setter and getter to the hash API and change it to hash.createHash() ? Of course we can also set a safe default. >>> 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. OK, sounds good > 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. yes. this is something on the back burner that I need to figure out now. >> It is an object literal that you store discovered public keys in - which are >> referred to as "addressbook entries"... > 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. I will, I have been treating this as a separate bug at Moz, and all of the feedback I have gotten is - "not yet, not now" - consider it removed it will have to be perhaps a part of an identity API of some kind >> 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. Yes. The entire API should be gatekept by a geolocation style authorization step. > 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. I will, I am a complete newbie to spec authoring, please bear with me as I make all of the changes and >>> 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? I am. I think that while all of these details are hashed out it is prudent to keep it separate, but consolidation with crypto is the best bet. This criticism and feedback is great. Thanks again! (keep it coming). David
