Hello, Francois ... A new smart card O/S we built recently has both PKCS#11 and #15 on the card. This makes customizing and administering card crypto a breeze and puts the #11 semantics at the card edge where they belong (IMHO).
Historically, the downside of #11 has been that its functionality gets split in a vendor-specific and application-unknowable way between the host and the card. Not only is this a security risk because you don't know what is being done securely on the token and what is being done in the open on the host but it also defeats token portability. Programming interfaces and physical interfaces must be coincident if portability and physical interoperability is to be achieved. #15 gets it right by putting all the key material on the card and providing card-edge semantics for navigating it. By putting #11 on the card the two can travel together and portability and interoperability of both cryptographic material and cryptographic operations is achieved. Cheers, Scott -----Original Message----- From: Francois Leclerc To: [EMAIL PROTECTED] Sent: 12/7/01 3:02 PM Subject: Re: MUSCLE Musclecard architecture George, Please use PKCS #11 for applications: .It is the langua franca API for tokens .Mozilla and a lot of commercial applications are using pkcs#11 .For a token vendor, it means less APIs to regression test, lower cost & safer products. ... > Actually this is very similar to what we were doing for KDE 3.0 as well. I > was unaware of this work and we were developing a similar system using shared > libs loaded on demand for "card implementations". All in C++ using KDE > classes though. I'm wondering if maybe we should abandon that or rework it > to use this now. I am working with GPK cards and the other person is using > GSM cards. > > We wanted to implement a very abstract architecture so that KDE > applications could use smartcards without having to know the details of them. > In particular, this would be used for storage, SSL certificates, and KDM > login. > > Would it make sense for us to make a KDE friendly wrapper around this code > instead? > > -- > *************************************************************** Unix Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/ To unsubscribe send an email to [EMAIL PROTECTED] with unsubscribe sclinux *************************************************************** *************************************************************** Unix Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/ To unsubscribe send an email to [EMAIL PROTECTED] with unsubscribe sclinux ***************************************************************
