Adam Megacz wrote:
Ken Hornstein <[EMAIL PROTECTED]> writes:
Maybe it's me, but I've never really seen the difference between a junk
certificate and a Kerberos ticket;
Somebody with no prior trust relationship can check the validity of a
junk certificate.
Not nessesarily. Only if the CA certificate used to sign the "junk
certificate" is trusted in some way. kx509 can could be setup to use
a self-signed CA certificate or a CA certificate signed by some higher
level CA. In either case there is some trust relationship be it specific
or implied.
I'm confused; do you know about some cryptosystem that I don't that
doesn't require users to know some sort of key?
Asymmetric cryptography eliminates the need for the party verifying
the key to share a secret with the certificate issuer.
This is the problem with Kerberos when you try to expand beyond a
single administrative domain (or more than a few for whom it is
feasible to do N^2 cross-realm): you have to hunt down the KDC admin
and cajole him/her into doing you a favor.
And this is where PKINIT may play a much bigger roll. The "cross trust"
is done at the PKI level, and certificates are enrolled in the local realm
as needed.
We may see this when the HSPD-12, NIST PIV smartcards start being used
across the federal government. If implemented correctly, the agency CAs
should be trusted by other agencies using the federal bridge CA.
This may complicate the client side, as the client may have to have
Kerberos tickets from multiple sites that don't do Kerberos cross realm
but do trust the user's certificate.
This works fine for a certain set of organizations, which, as a
result, have been the only ones who use Kerberos (and hence AFS for
the most part).
Kerberos was designed in an era when computers were much slower and
the (much greater) computational burden of asymmetric cryptography was
a serious problem. This is no longer the case.
- a
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
