On Fri, Jun 24, 2011 at 11:00 AM, Marsh Ray <ma...@extendedsubset.com> wrote: > On 06/24/2011 02:04 AM, Nico Williams wrote: >> >> Every bank that uses Active Directory uses Kerberos, and the GSS-like >> SSPI. And the Kerberos GSS mechanism (through SSPI, on Windows). The >> native Windows TLS implementation is accessed via SSPI. > > I've used/abused the Windows SSPI a few times for various things. It's > pretty darn abstract. Which is not a criticism, only that it's less of an > API than a intra-host transport protocol for shipping loosely related > structures between apps and the security providers which are as diverse as > Kerb and TLS.
I'm not sure what you mean by "abstract". What I mean when I say "abstract API" is what you see in RFC2743: an API described in generic terms and notation rather than in any on programming language. >> http://msdn.microsoft.com/en-us/library/aa375506%28v=vs.85%29.aspx > > For example, the Microsoft doco on InitializeSecurityContext() > has a description and then again separate pages for every security support > provider (SSP) that ships with Windows. That's kind of annoying, I agree. Other OSes don't do that. For example, there is no separate manpage for each mechanism's gss_init_sec_context() entry point in any Unix or Linux that I know of. Part of the reason MSFT does this, I suspect, is that they've come to use SSPI for so many things (TLS, SASL, GSS). > Again, there's nothing wrong with this. But I suggest a guideline for our > discussion of the design of crypto APIs: The API must not be so abstract > that it doesn't actually encrypt any data. Huh? SSPI sure does have functions for encrypting data. The init sec context function isn't it -- that's for authentication and key exchange. Nico -- _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
