On 2012-01-03 23:44, Robert Relyea wrote: > On 12/30/2011 06:53 AM, Anders Rundgren wrote: >> On 2011-12-29 23:08, Brian Smith wrote: >>> Matej Kurpel wrote: >>>> On 22. 12. 2011 10:36, Imen Ibn Hotab wrote: >>>>> I`m developing pkcs#11 module for Firefox. >>>> I was developing a PKCS#11 module as well. >>> Just out of curiosity, what do your PKCS#11 modules do? >>> >>> Would it make things easier for either of you if Firefox and >>> Thunderbird supported CAPI CSPs in addition or instead of >>> pkcs#11 modules for client certificates on Windows? >> Yes! I think Firefox would gain by in addition to PKCS #11, >> also support the native OS crypto system (if there is one). >> >> Cheers, >> Anders > There is a capi module in the NSS source tree, but it purposefully does > not surface removable CAPI modules under the assumption that such > devices already have PKCS #11 modules.
I'm not sure what you mean with "removable CAPI modules" but the assumption that PKCS #11 is standard on Windows is not entirely correct since PIV cards (for example) can be "as is" in W7 and forward without any middleware installation. Other cards may need an install via Windows Update but this (AFAIK) does usually not include PKCS #11. Chrome uses CAPI by default. OTOH, the situation is the same for Java. The Oracle JRE contains built-in support for CAPI not needing any setup or configuration. Well, there is support for PKCS #11 but it requires much more work to be used. BTW, integration of crypto seems to have taken a giant leap forward: http://channel9.msdn.com/Events/BUILD/BUILD2011/HW-462T http://www.google.com/wallet I think this step was inevitable; supporting third-party drivers and custom enrollment schemes have simply proved to be too hard if you are targeting consumers. That the inside of the schemes above currently are kept under wraps is an indication of that this field is slowly but surely heating up :-) If the unverified rumor that Google's Wallet is based on GP (GlobalPlatform) actually is true, it looks like E2ES (end-to- end-secured) provisioning will be "the next big thing" in crypto middleware. It will be quite interesting to see how this is going to be dealt with by Mozilla as well as by the *NIX community. My take on this (as you have heard about a gazillion times before), is defining a unified E2ES-enabled crypto container (SKS) so that you in the majority of cases would never have to bother about middleware in a "contemporary" platform. SKS differs from GP in many respects, most notably in the trust model where GP assumes that the container trusts the issuer which mainly is a smart card "business model" issue rather than a security requirement. In SKS it is the user who grants an issuer the right creating a key based on the existing (semi-functional) Internet trust model. Since a fake key doesn't open any genuine doors, this should work just fine. Anders > > bob >> >>> Cheers, >>> Brian > > > > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
