[OpenAFS] "automatic" gssklog [was: final prerequesite for world domination]

[Adam Megacz]

"Douglas E. Engert" <deengert@anl.gov> writes:
>> There are a lot of competing solutions and partial-solutions out
>> there (gssklogd, kx509, pkinit),

> Well, I can speak for gssklog, It does not do identity management.

I think the "identity management" bit is kind of beyond the scope of
what I'm hoping for.  Actually, aside from the level of automation,
gssklog is pretty much what I want (I managed to get it working a few
months ago and was pretty happy) -- I just would like it to be more
standard and automatic, and I'm trying to figure out if my effort
would be wasted in coding towards such a goal.

Let me put it this way: if suitable, high-quality code were to be
written, would OpenAFS be interested in integrating gssklog into the
client (cache manager) in an "automatic" fashion?  One possible
definition of "automatic" would be:

  - Let "fs sa" take an X.509 key file as an argument instead of a
    user, and have it automatically create a pts id if one does not
    exist for said key (probably requires an extra RPC call, and there
    are some details to be worked out here for sure -- topic for
    discussion).  How you get that key file is outside the scope of
    this proposal.

  - The short form output of "fs la" for these special pts ids would
    include the DN and a "fingerprint" of the X.509 key (~8-10 chars).
    A "long form" option would show the whole key.

  - The user would be able to load private keys into [non-swappable,
    kernel] memory on the client, and the cache manager would
    automatically obtain and renew tokens for cells as needed based on
    those keys (removes the need to invoke gssklog for every cell you
    work with, every 10 hours).  Some sort of inactivity metric for
    forgetting these keys is probably adviasble.

With all this talk about PKI and commercial CA's and identity
management, something as simple as the above (or equivalent to it
somehow) is all I'm looking for.  By putting all those issues behind a
reasonably well-accepted API (X.509 in this case), we can avoid forcing
a particular solution to all those other really-hard-problems on
people.

  - a