You might say that the GSS-API is very TL-y or SASL-y too, since MSFT's SSPI (which is very similar to the GSS-API) has an interface to TLS and to SASL as well as to NTLM and the Kerberos GSS mechanism.
Martin Rex found the TLS renegotiation bug independently from Marsh Ray by thinking of how the SSPI is used to interface to TLS. The SSPI was so faithful to TLS that it really exposed the bug. Of all the Internet standards-track authentication frameworks and mechanisms, the least GSS-y is EAP, and even *that* is being bridged so it can be used in the GSS-API (with the peer and NAS as GSS initiator and acceptor, respectively). There's nothing terribly special to the GSS-API other than being an abstract interface to any security mechanism that authenticates clients to services and/or vice-versa. It doesn't cover S/MIME nor PGP -- it can't really do disconnected communications. But that's it. Back to the topic at hand: I don't understand why you'd want to create a new API that abstracts the GSS-API and PKCS#11. I'd like to know more about what the OP has in mind. The links posted say nothing about the subject. I *do* think that the PKCS#11 API is quite clunky. WOrk on *that* would be good. Nico -- _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
