On 8/14/2011 10:40 AM, Anders Rundgren wrote: > On 2011-08-14 08:59, Alon Bar-Lev wrote: >> There had been always unified API: PKCS#11. >> Well, at Microsoft environment there was CryptoAPI Provider. >> The good about the CryptoAPI is that it allowed enough flexibility so >> that, for example, you could have created a generic CryptoAPI provider >> on-top of PKCS#11. >> >> In the MiniDriver, Microsoft advanced too far. It created a dependency >> between Microsoft specific data and on-card implementation. It also >> created a dependency between configuration and card content. >> >> So now, instead of providing a single API (PKCS#11) and a single >> bridge for Microsoft environment (CryptoAPI Provider->PKCS#11) you >> need to work much harder. >> >> Alon. > > PKCS #11 is great as a "user" API. > > As the foundation for an online provisioning API it seems more limited. > RedHat do not use PKCS #11 in their DogTag Card Management System > for this reason although they support a limited set if cards. > > The reason for bringing this up is that suddenly the interest for creating > a browser-based provisioning system has even reached Google (!) and then > the question about middleware is popping up. I'm less optimistic that > you can create a useful system which can be used by consumers > without doing something creative in the lower layers as well. > > Microsoft is (based on "indirect" information...), also working on a new > enrollment system which builds on the MiniDriver.
But which browsers? IE can use the minidriver, FireFox can use NSS that uses PKCS#11. Apple has is CDSA. I am not sure what newer Android or WebOS browsers can use. This paper offers some more insight and a creative approach: http://w2spconf.com/2009/papers/s4p4.pdf > > Anders > >> On Sun, Aug 14, 2011 at 7:20 AM, Anders Rundgren >> <anders.rundg...@telia.com> wrote: >>> Writing card drivers is quite difficult. That's why Microsoft introduced >>> the "MiniDriver". >>> >>> The driver model has been very successful for printers since printers have >>> widely different characteristics. Cryptographic operations OTOH leave very >>> little (if any) room for variations. >>> >>> Although cards may differ in features, using unified high-level APIs like >>> the MiniDriver this will either be hard to access or more likely: Never be >>> utilized. >>> >>> Open question: Since the MiniDriver gives a unified card API, wouldn't it >>> be easier defining a FIXED API/DRIVER and rather let the cards adapt to >>> that? Certifying a gazillion third-party drivers including multiple card >>> versions doesn't appear to be a particularly swift project. >>> >>> With a fully unified card API you can target all cards with a fairly simple >>> test-suite and delegate the certification to the card vendors. This should >>> dramatically improve system reliability which always has been a weak point, >>> particularly for consumer computers. >>> >>> Anders >>> >>> _______________________________________________ >>> opensc-devel mailing list >>> opensc-devel@lists.opensc-project.org >>> http://www.opensc-project.org/mailman/listinfo/opensc-devel > > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel > > -- Douglas E. Engert <deeng...@anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
