> ?? That's not the primary purpose at all. In fact, I'd be rather
> surprised if PK significantly reduces administration, if at all.
It is the primary argument I hear from people when choosing between
authentication systems. People say they would rather implement
something based on public keys than Kerberos because Kerberos has a
higher administrative cost and the cross realm work is too high.
As far as I can tell the work levels are equivalent.
> Not necessarily - it rather depends what you think a cert says (which
> depends on the CA, of course). If you think it says "this belongs to X"
> (what most CAs support), then it _is_ authentication. If you think it
> says "the holder of this cert can do X" (rather akin to Thawte's add-on
> whose name I forget), then you've got a point. I suppose there's even
> room for certs not tied to particular identities at all, which I'd guess
> would be called "bearer certificates" in other circles. Or capabilities,
> even.
The problem is that a random cert really says "I am unique identifier
Y". Then a local mapping needs to be provided for 'Y' to the local
Unix, Windows, ... identifiers. So I need to have access to the certs
before they can be used for authentication. Once I have the local
userid I can then use Attribute certs or other methods for determining
authorization.
I don't think we are in disagreement. I think we agree that the
global PK infrastructure is not in place yet. Therefore, we need to
handle PKI on a local basis where each of us probably is doing
something slightly different and incompatible.
> Aha. OK, I take your point. This would have to be TLS v2, of course, coz
> its too late for TLS v1.
I agree. The TLS WG is looking for things to do. This might be a
good place to start.
> I have to admit that I'm not familiar with SASL ... pointer?
RFC 2222 "Simple Authentication and Security Layer" is the base protocol
document. It is at the Proposed Standard level. This is then updated
by RFC 2444 "The One Time Password SASL Mechansim".
In addition, there are Internet-Drafts for SASL mechansims that
support Secure Remote Password, Kerberos 4, Kerberos 5, and several
other authentication mechansims.
The general idea is to allow applications to share a common
authentication library.
There is a mailing list http://www.imc.org/ietf-sasl/
And an implementation library at
ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/cyrus-sasl-1.5.11.tar.gz
Let's take this private after this reply.
Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
The Kermit Project * Columbia University
612 West 115th St #716 * New York, NY * 10025
http://www.kermit-project.org/k95.html * [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
