Hi Alon, sorry I missed your response since it got filtered away without me being aware.. Better late than never, I suppose..
On Mon, 2 Jul 2007 21:47:46 +0300 "Alon Bar-Lev" <[EMAIL PROTECTED]> wrote: > On 7/2/07, Bud P. Bruegger <[EMAIL PROTECTED]> wrote: > > Hi Alon, > > > > have you already made progress in the implementation? I was very > > interested in this since I'd like to write some non-traditional pkcs#11 > > module and I'd prefer to do that in python... I was wondering whether > > the forwarding driver could be a good fit for this... > > No, I had no time yet. > But now, after KDE guys deferred smartcard integration in a year, I > probably have some time. Have you had a chance to work on it in the meantime? > > In more detail, instead of using a static, local token, I would like to > > interface the pkcs#11 to a dynamic certificate: the middleware first > > creates a keypair, sends it off to a CA that issues a certificate on > > the fly, and then presents that through the pkcs#11 interface. > > > > Will this kind of thing be possible? > > I don't think so. > There is no valid common sequence that will allow you to do this. > I also don't see the use case, can you please explain? The use is what I call TLS-Federation. Using plain old TLS (or SSL) with client-cert-authentication is kind of my favorite approach since it is simple, works, and is well proven. Europe wants interoperability of eIDs by 2010 and does so while leaving full autonomy to Member States what kind of electronic identities they issue. So while most states issue some X.509-based smartcards, some issue non-X.509 smartcard eIDs, and some even use username password. So Europe seeks a "Federated" solution that works with all these eIDs. Plain TLS works only with X.509 eIDs and is thus not a possible solution--at least without an extension that makes it federated ;-) So TLS-Federation means that for non-X.509 eIDs, a certificate is issued on the fly by an Identity Provider (really a plain old CA) that authenticates with the country specific (mostly proprietory) authentication mechanism and then issues a cert that can be used in the TLS-handshake (with a keypair that is generated by the middleware). If ever possible, I'd like to wip up a proof of concept to demonstrate at Porvoo 12 on October 18/19--and your project seemed to make it possible that I wip up the base functionality in python... This was a very brief description--let me know whether it was too brief to convey any sense.. best cheers -b > > Alon. -- Ing. Bud P. Bruegger, Ph.D. +39-0564-488577 (voice), -21139 (fax) Servizio Elaborazione Dati e-mail: [EMAIL PROTECTED] Comune di Grosseto jabber: [EMAIL PROTECTED] Via Ginori, 43 http://www.comune.grosseto.it/ 58100 Grosseto (Tuscany, Italy) http://www.comune.grosseto.it/interopEID/ _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
