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

Reply via email to