- From: David Dahl <ddahl@mozilla.com>
- Date: Thu, 7 Jun 2012 20:48:43 -0700 (PDT)
- To: Ryan Sleevi <sleevi@google.com>
- Cc: Mark Watson <watsonm@netflix.com>, GALINDO Virginie <Virginie.GALINDO@gemalto.com>, public-webcrypto@w3.org
----- Original Message ----- > From: "Ryan Sleevi" <sleevi@google.com> > To: "David Dahl" <ddahl@mozilla.com> > Cc: "Mark Watson" <watsonm@netflix.com>, "GALINDO Virginie" <Virginie.GALINDO@gemalto.com>, public-webcrypto@w3.org > Sent: Thursday, June 7, 2012 5:12:21 PM > Subject: Re: [W3C Web Crypto WG] Deciding if we need a discovery mechanism > Thanks for taking a stab at this. I think the choice of discovery > API, and > the behaviour such as whether it throws an error/exception, must be > very > closely tied with how the final API looks. That is a great observation. Perhaps the exception is not such a good idea. > Thus, it's hard to > evaluate this > proposal without also understanding how you might see the use of > RSA-OAEP > and the use of ECDH-ES working, using crypto.pk.algorithms.keyenc as > an > example. > > The reason I mention this is that I'm trying to think of how a web > developer might extend the API locally when a given user agent does > not > support a desired algorithm/cryptographic primitive. Let us say, for > example, that a U-A is able to implement all of the algorithms except > for > ECDH-ES. The web developer may wish to implement ECDH-ES purely > within > JavaScript for these cases (ignoring the bignum constraints, etc). > How they > do so depends on what the API looks like. > I hope this scenario is an extreme edge case:) > If algorithms are objects, you might imagine that it would be as > simple as: > > var ecdh_alg = window.crypto.pk.keyenc.ecdh_es || my_local_ecdh_es; > var my_key_encryptor = ecdh_alg(arg1, arg2, arg3); > Yes, this is elegant. I will re-evaluate what I was doing and work from your ideas on this. Thanks! David
Received on Friday, 8 June 2012 03:49:13 UTC