On Mon, Oct 28, 2013 at 2:03 PM, <florian.ben...@quantumedia.de> wrote:
> On Monday, October 28, 2013 1:50:42 PM UTC+1, helpcrypto helpcrypto wrote: > > Something similar to Webcrypto should work, but having user keys in mind. > > AFAIK, WebCrypto[1] is the replacement for the current window.crypto (and > the reason why the latter one should be dropped). > > If there's anything WebCrypto does not cover, please contact and ask the > WebCrypto folks[2] to consider your use case. > > There are (outdated) shims[3] available for WebCrypto (or realted > APIs[4]). Do they, or the WebCrypto specification[1], cover your use case? > > > [1] http://www.w3.org/TR/WebCryptoAPI/ > [2] http://www.w3.org/2012/webcrypto/ > [3] http://polycrypt.net/ > [4] http://crypto.stanford.edu/sjcl/ > Already done that. WG people said user keys are out of scope. See [1] Maybe im lost on the translation, but seems they dont consider *key *can be retrieved from keystores when doing *sign(key, data)* On Mon, Oct 28, 2013 at 2:12 PM, Mountie Lee <moun...@paygate.net> wrote: > Hi. > I'm from Korea which is one of the countries widely using plugin based > crypto technologies. > also I'm the member of W3C WebCrypto WG. > > I feel with current draft WebCrypto spec, it can not be the replacement of > plugins (java applet, activex, npapi...) > > the signature can be generated SILENTLY without notice to user. > it depends on server implementation. > > I feel similar difficulties of helpcrypto's comment. > > regards > mountie. > IMHO it's as simple as adding a *getKey(keystore, filter)* function. I understand there are several concerns regarding "user knowing what's signning", but that another story we could discuss if -at least- we could do sign with user keys on keystore. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
