Anish,
This is actually more than I described. I had hoped to keep the
responder logically separate from the CA, so that the CA could be
kept off-line, if desired. To have an "automated" responder which allowed
the CA to sign messages in this manner, you would have to have on-line
access to the CA's private key. If you (or anyone else) can convince me
that this does not pose a security threat to compromise the CA, I am open
to the idea. For now, though, I stand by my idea of having repositories be
untrusted.
I made the comment (about having a responder do more than just respond with
certificate - but to actually confirm their current validity) just to be sure
that
you had seen the discussion.
Your concern about having to have the CA's private key on line is valid, and
I know that Steve Kent has expressed similar concerns. The problem is not
necessarily hopeless, however. I can imagine a n adjunct processor that is
not directly connected to the Internet, but which accepts a request from a
gateway or firewall processor over a dedicated link and returns only the signed
result.
The private key that is used for the purpose of confirming the validity of a
certificate chain should NOT be the private key that corresponds to the CA's
certificate that is signed by the PCA. Instead, the CA should (offline) generate
a key pair and a certificate for the certificate confirmation function, and it
is
that private key that would potentially be exposed on line.
If necessary or desirable, that private key and certificate could be generated
afresh every 24 hours, in order to limit the potential impact of that private
key
somehow being compromised.
However, even if the certificate confirmation key were compromised somehow,
it wouldn't be the end of the world, because the CA could later disavow that
certificate via a CRL. It would be an extraordinary event, and it would
complicate
nonrepudiation, but the system could recover.
Bob