Well, there are plenty of applications where you can perform key and certificate
maintenance from a web interface. There are typically buttons to generate
or import keys, to generate and export certificate signing requests, and to
import certificates and chains. That much is not in question.
To do this with the Citadel system, the agent acting on behalf of the site
would be WebCit, not Citadel Server. This breaks our data model somewhat
because we would require a true keystore *in* Citadel Server, which would
then have to deliver the private key to WebCit when it starts up, so that
WebCit can serve up SSL sessions. The reason this breaks our data model is
because WebCit is currently not trusted -- it only has the security level
of the user who is logged into it. A central design tenet has always been
that the client on the other end of the 504 protocol is no more trustworthy
than
an end user; a protocol connection has the same security level as a telnet
connection.
Key management from WebCit will require the addition of some sort of trust
model. I suppose each instance of WebCit will have to generate its own identity
the first time it starts up, and register itself with Citadel Server the first
time an Administrator logs in. Then on subsequent startups it would use that
registration to download the private key and the certificate.
I hate this but I'm unable to think of any other way.
