Re: Feedback on DOMCryptInternalAPI

2012-05-13 Thread helpcrypto helpcrypto
Yesterday thoughts: Some policies say "Before signing, a preview of what is going to be signed must be shown to the user". If we use something like: signedData=sign(key,dataToBeSigned) this could show, for example, a pdf preview of what is being signed. I love that idea, but what if i actua

Re: Feedback on DOMCryptInternalAPI

2012-05-03 Thread Kyle Hamilton
On Thu, Apr 26, 2012 at 12:32 AM, helpcrypto helpcrypto wrote: Supporting smart cards in the spec and first implementations is not a goal, however, I think a lot of the base work we are doing will help in a future iteration. For instance, I hope that this Gecko 'internal API' will help ext

Re: Feedback on DOMCryptInternalAPI

2012-05-03 Thread Kyle Hamilton
On Thu, May 3, 2012 at 4:27 PM, Wan-Teh Chang wrote: David, Here are my review comments on https://wiki.mozilla.org/DOMCryptInternalAPI: 1. I don't understand the difference between the two methods that generate key pairs:    PKGenerateKeyPair    SigGenerateKeyPair GenerateKeyPair(purpose:

Re: Feedback on DOMCryptInternalAPI

2012-05-03 Thread Kyle Hamilton
David, I'll go into my vision of what I aspire to ("The Truly Universal PKI") in another message. Why I focus on what I do may become clearer then. tl;dr: 1. CMS is the primary motivator for BER indefinite reading, if not writing/digesting. 2. To prevent ECB and non-KDF key agreement, enumera

Re: Feedback on DOMCryptInternalAPI

2012-05-03 Thread Kyle Hamilton
On Thu, Apr 26, 2012 at 12:32 AM, helpcrypto helpcrypto wrote: Supporting smart cards in the spec and first implementations is not a goal, however, I think a lot of the base work we are doing will help in a future iteration. For instance, I hope that this Gecko 'internal API' will help ext

Re: Feedback on DOMCryptInternalAPI

2012-05-03 Thread Wan-Teh Chang
David, Here are my review comments on https://wiki.mozilla.org/DOMCryptInternalAPI: 1. I don't understand the difference between the two methods that generate key pairs: PKGenerateKeyPair SigGenerateKeyPair 2. PKEncrypt just need a public key, not a key pair. 3. I suggest not assigning

Re: Feedback on DOMCryptInternalAPI

2012-04-27 Thread ianG
On 26/04/12 22:24 PM, helpcrypto helpcrypto wrote: If you want the signature + document to be legally sustainable and/or user-interpretable, then plaintext signatures with embedded public keys are the way to go. You can base64-encode the public keys :) Some further development of this theme is

Re: Feedback on DOMCryptInternalAPI

2012-04-27 Thread ianG
On 26/04/12 17:32 PM, helpcrypto helpcrypto wrote: Are you saying you base64 encode the data to be signed before the signature is created? No. Let me show you an example. Consider you provide this API: sign(keyId, data) IMHO, the correct way of invoking wil be: sign(1,"ZGF0YXRvYmVza

Re: Feedback on DOMCryptInternalAPI

2012-04-26 Thread David Dahl
- Original Message - > From: "ianG" > To: dev-tech-crypto@lists.mozilla.org > Sent: Thursday, April 26, 2012 6:14:43 AM > Subject: Re: Feedback on DOMCryptInternalAPI > > > I don't imagine we will have an address bound the the public key. >

Re: Feedback on DOMCryptInternalAPI

2012-04-26 Thread helpcrypto helpcrypto
> If you want the signature + document to be legally sustainable and/or > user-interpretable, then plaintext signatures with embedded public keys are > the way to go.  You can base64-encode the public keys :)  Some further > development of this theme is at > http://iang.org/papers/ricardian_contrac

Re: Feedback on DOMCryptInternalAPI

2012-04-26 Thread ianG
(couple of off the wall observations, 'scuse the fast typing...) On 26/04/12 01:53 AM, David Dahl wrote: I have experienced some issues regarding to encoding. A page encoded in ISO send some data to a page encoded in UTF-8 which signs...then, verify could not match. So we decide to use base64

Re: Feedback on DOMCryptInternalAPI

2012-04-26 Thread helpcrypto helpcrypto
> Supporting smart cards in the spec and first implementations is not a goal, > however, I think a lot of the base work we are doing will help in a future > iteration. For instance, I hope that this Gecko 'internal API' will help > extension and browser developers to experiment with smartcards,

Re: Feedback on DOMCryptInternalAPI

2012-04-25 Thread David Dahl
- Original Message - > From: "helpcrypto helpcrypto" > To: "David Dahl" > Cc: "dev-platform" , "mozilla's crypto code > discussion list" > > Sent: Wednesday, April 25, 2012 3:12:23 AM > Subject: Re: Feedback on DOMCryptI

Re: Feedback on DOMCryptInternalAPI

2012-04-25 Thread helpcrypto helpcrypto
> for signWithUserConfirmation > as I know, that requirement was raised because of regulations of some > countries. > it is UI specific function and need some fixed UI (already > mentioned spanish DNIe) > I think we need some control for that with CSS style > the very important concept is "the cont

Re: Feedback on DOMCryptInternalAPI

2012-04-25 Thread Mountie Lee
Hi. I'm from Korea. let me comment something more. for signWithUserConfirmation as I know, that requirement was raised because of regulations of some countries. it is UI specific function and need some fixed UI (already mentioned spanish DNIe) I think we need some control for that with CSS style t

Re: Feedback on DOMCryptInternalAPI

2012-04-25 Thread helpcrypto helpcrypto
Just some commets you could ignore :P As said before, i dont know if you have considered smartcard. These, (as discussed in https://groups.google.com/forum/#!topic/mozilla.dev.tech.crypto/hNS32Zhz9gw) could have some other needs. IMHO, a lot of discuss yet to come. I have experienced some issues

Re: Feedback on DOMCryptInternalAPI

2012-04-22 Thread Marsh Ray
On 04/20/2012 07:40 PM, Kyle Hamilton wrote: I'd like it to default to SHA2/256. This is particularly for deriving 256-bit symmetric keys from ECDH exchanged secrets. Is that SHA-2-256 or SHA-2-512/256 ? The latter seems to be gaining in popularity as it is slightly faster on 64-bit machines

Re: Feedback on DOMCryptInternalAPI

2012-04-20 Thread Anders Rundgren
On 2012-04-19 17:09, David Dahl wrote: > Hello All: > > [I have cross posted this message to dev-platform and dev-tech-crypto, > perhaps we should discuss this on dev-platform as it has a larger subscriber > base?]. > > I am just putting together a draft feature page for an internal API needed by

Re: Feedback on DOMCryptInternalAPI

2012-04-20 Thread David Dahl
- Original Message - > From: "Kyle Hamilton" > To: "mozilla's crypto code discussion list" > > Cc: "Justin Lebar" > Sent: Friday, April 20, 2012 7:40:12 PM > Subject: Re: Feedback on DOMCryptInternalAPI > >> > >&

Re: Feedback on DOMCryptInternalAPI

2012-04-20 Thread David Dahl
- Original Message - > From: "Justin Lebar" > To: "David Dahl" > Cc: dev-tech-crypto@lists.mozilla.org > Sent: Friday, April 20, 2012 8:38:53 PM > Subject: Re: Feedback on DOMCryptInternalAPI > > Is > > https://wiki.mozilla.org/Pri

Re: Feedback on DOMCryptInternalAPI

2012-04-20 Thread Justin Lebar
l MAC all encrypted messages and reject decryption with invalid MACs. On Sat, Apr 21, 2012 at 11:19 AM, David Dahl wrote: > - Original Message - >> From: "Justin Lebar" >> To: "David Dahl" >> Cc: dev-tech-crypto@lists.mozilla.org >> Sent: Fri

Re: Feedback on DOMCryptInternalAPI

2012-04-20 Thread David Dahl
- Original Message - > From: "Justin Lebar" > To: "David Dahl" > Cc: dev-tech-crypto@lists.mozilla.org > Sent: Friday, April 20, 2012 6:31:02 PM > Subject: Re: Feedback on DOMCryptInternalAPI > > (Not cross-posting to dev-platform per Mounir&

Re: Feedback on DOMCryptInternalAPI

2012-04-20 Thread Kyle Hamilton
[dev-tech-crypto followup] On Fri, Apr 20, 2012 at 8:11 AM, David Dahl wrote: We could also return the hash or hmac producing object like: var h = window.crypto.hash(alg); This would be the most general way to handle it. (I'm told that 'generality is the key'.) Why is it that I get

Re: Feedback on DOMCryptInternalAPI

2012-04-20 Thread Justin Lebar
(Not cross-posting to dev-platform per Mounir's plea, and because I don't think these details are particularly interesting to that audience.) >> > interface CryptoHmac { >> >> Why isn't this CryptoMac?  Surely the fact that it's an hmac is an >> implementation detail. > > Sure, I don't imagine sup

Re: Feedback on DOMCryptInternalAPI

2012-04-20 Thread David Dahl
- Original Message - > From: "Justin Lebar" > To: "David Dahl" > Cc: dev-tech-crypto@lists.mozilla.org > Sent: Friday, April 20, 2012 2:22:31 AM > Subject: Re: Feedback on DOMCryptInternalAPI > > I don't know if you're at the bikes

Re: Feedback on DOMCryptInternalAPI

2012-04-20 Thread Justin Lebar
l" > To: "Ehsan Akhgari" > Sent: Thursday, April 19, 2012 3:09:45 PM > Subject: Re: Feedback on DOMCryptInternalAPI > > Ehsan: > > This API will not interact with PB mode, except that it will need to store > keys either in the NSS db or elsewhere. Of course no

Fwd: Feedback on DOMCryptInternalAPI

2012-04-19 Thread David Dahl
[Forgot to reply all] - Forwarded Message - From: "David Dahl" To: "Ehsan Akhgari" Sent: Thursday, April 19, 2012 3:09:45 PM Subject: Re: Feedback on DOMCryptInternalAPI Ehsan: This API will not interact with PB mode, except that it will need to store keys eit

Re: Feedback on DOMCryptInternalAPI

2012-04-19 Thread Ehsan Akhgari
Hi David, What is your concern here with regard to the private browsing mode? It's not immediately obvious to me why and how this API should interact with the PB mode. Thanks! -- Ehsan On Thu, Apr 19, 2012 at 11:09 AM, David Dahl wrote: > Hello All: > > [I have cro

Feedback on DOMCryptInternalAPI

2012-04-19 Thread David Dahl
Hello All: [I have cross posted this message to dev-platform and dev-tech-crypto, perhaps we should discuss this on dev-platform as it has a larger subscriber base?]. I am just putting together a draft feature page for an internal API needed by the eventual DOM bindings for DOMCrypt (see: http