>Kyle wrote >> As for Firefox, the only thing which can be used via JavaScript is >> signtext. If there were a crypto object in the DOM which could >> support more than just signtext, it would be quite nice -- but there >> isn't one as far as I've been able to tell. (I have not looked that >> closely, however.)
Peter D wrote: >I'm surprised. Are there any plans to export more of the functionality >through the PSM module or in any other way? Actually the problem is [quite] a bit trickier than exporting APIs. A browser can be regarded as a Virtual Machine (VM), typically running *untrusted* application code (e.g. downloaded HTML pages), in a sandbox mode. Cryptographic libraries are OTOH programmatic interfaces supposed to be called by *trusted* applications. AFAIK, neither the concept of an interactive user or a display is a part of such. That is, what is missing is not really an API, but a secure "bridge" between the user, GUI, browser and the crypto libraries. "signText ()" is a minimal version of such a bridge. Missing US Government requirements The reason why this is not happening is that there are no requirements from the US government for signature support in browsers. The disparate governments in the EU and Asia (who have such requirements), are unable to run this as a united effort. This is hardly surprising because such missions are outside of the scope of most governments. That the US government is a crucial player in this space is due to the dominance of the US SW industry, as well as their use of English :-) PKI is [still] a "research" topic In addition, there is a lot of confusion in this space when you start to design systems which makes it hard to come up with a specification. http://w1.181.telia.com/~u18116613/A.R.AppliedPKI-Lesson-1.pdf http://w1.181.telia.com/~u18116613/A.R.AppliedPKI-Lesson-2.pdf If you (all) have a solution to these questions that use true E2ES (End-To-End-Security), I would like to hear about this! So far nobody have dared to *publish* how such a system would work. That this has implications is because it affects "what to sign"; the actual transaction, or just a locally stored "assertion" associated with the out-going transaction. To sign the actual transaction would require the browser to handle any number of protocols and formats, as well as doing message encryption. IMO, such a thing will never fly. Therefore I have in my related WASP work, made signining transactions directly, as out of scope. That this [in the eyes of some people] violates the core of PKI is something I consider of little importance since the assertion method is the de-facto standard in practically all existing pre-PKI transaction schemes. Anders R _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
