Packing Kerberos Tickets into X.509 certificates

[Rick van Rein]

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