[cryptography] IETF Working Group Charter on Common Interface to Cryptographic Modules (CICM)
nico at cryptonector.com
Tue Jun 21 11:27:26 EDT 2011
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.
More information about the cryptography