On 8/16/07, Bud P. Bruegger <[EMAIL PROTECTED]> wrote: > Hi Alon, > > sorry I missed your response since it got filtered away without me > being aware.. Better late than never, I suppose..
Sure! > Have you had a chance to work on it in the meantime? No. I was working on PKC#11 for gnutls and some suspend stuff and other projects... Sorry... > 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). I don't understand!!! If you issue X.509 certificate on one authentication event, why can't you issue it for longer time? I also don't understand who will trust this authentication CA... As it much simpler to implement Kerberos with SPNEGO. The temporary X.509 certificate surely should not be a formal way to establish authentication infrastructure... But I have seen worse. Best Regards, Alon Bar-Lev. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel