Hi Bryce, > I may be asking a question which exposes either my ignorance or lack > of imagination, but is there a reason a kx509 (RFC6717/RFC4556) > certificate wouldn't work? Wouldn't it be easier to add support for > these previously defined extensions? > I'm happy to answer that of course; but my reason for asking here is to learn if people think it's offensive or abusive to put Kerberos structures into PKIX structures. Since it's a bit weird, but could nonetheless work well.
By the way, using this PKIX profile, and could run the kx509 self-signer on the client machine (which is just what the demo application shows). > As I understand it, the main difference between kx509 certificates and > your proposal is that in your proposal a shared secret exists between > the KDC and the recipient of the certificate; whereas a server > accepting kx509 certificates would just be configured to trust the > user's kx509 sign-er. Both use principal names defined by the KDC as a > back end identity store. > Yes, and the existing shared secret be the normal client-service relation under Kerberos, for which the service is sent a Ticket; this might span accross realms in whatever way Kerberos supports, now or in the future. For kx509, a separate signing infrastructure is setup under the KDC. Within a realm, it is doable to install the CA certificate on services, but when crossing over, anything that would need to be arranged on top of that makes the infrastructure more frail, more maintenance-intensive. Also, there are refined facilities in Kerberos that would be lost when moving over to X.509; things like passing on permissions for backend services. Thanks, -Rick ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos