On 2011-08-16 17:33, Douglas E. Engert wrote: > > > 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
SConnect represents a card vendor approach. I doubt SConnect actually withstands a thorough security analysis. Connecting to a smart card from untrusted browser code seems like an even worse idea than Microsoft's "CertEnroll". KeyGen2/SKS represents an issuer-oriented scheme where the "card" is slightly downplayed in favor for the identity ecosystem. Anders > >> >> 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 >> >> > _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
