Re: [opensc-devel] Rationale for Microsoft's MiniDriver
On 8/13/2011 11:20 PM, Anders Rundgren 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. Is this really an OpenSC question? There are cards out there by many vendors. They could, if they wanted to, do what you suggest but they continue to write their own drivers. OpenSC also provides a mini-driver for the cards supported by OpenSC. This bypasses the PKCS#11 and supports the PKCS#15 cards (and emulated PKCS#15 cards). PKCS#15 if more of a standard that many card vendors have adopted and Microsoft could have too. But early on they developed their own smart card, then tried to standardize around it, thus the confusing CAPI, CNG and its minidriver. As a side note, Microsoft with Windows 7, does provide a built in minidriver for at least the PIV card. Thus no 3rd party drivers including OpenSC is needed to use a PIV card. There are 15 appreved PIV cards, from 6 vendors: http://fips201ep.cio.gov/apl.php So this could be what you are looking for, but the PIV is not designed to be provisioned over the network. 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. True, if the card vendors could agree on one. Anders ___ 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
Re: [opensc-devel] Rationale for Microsoft's MiniDriver
On Aug 16, 2011, at 6:16 , Douglas E. Engert wrote: 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. True, if the card vendors could agree on one. http://xkcd.com/927/ -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Rationale for Microsoft's MiniDriver
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
Re: [opensc-devel] Rationale for Microsoft's MiniDriver
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
Re: [opensc-devel] Rationale for Microsoft's MiniDriver
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. 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
Re: [opensc-devel] Rationale for Microsoft's MiniDriver
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
[opensc-devel] Rationale for Microsoft's MiniDriver
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
