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. 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
