It seems like a common thread in several recent proposals is to have
CAs be willing to sign things in an interactive and potentially
automatable way. This would be handy for proving that keys were not
revoked at the time of signature and other sorts of extended
non-repudiation services.
While there is a lot of potential here, there is also a threat of
fundamentally weakening the security of our infrastructure. One of the
greatest advantages of public key cryptography is its support for an
off-line introduction agent. If it's on the network, it's subject to
network based attack. I would hate to see us give up that advantage
for some add-ons. I see CRLs as the first threat of this sort. If
people want CRLs to be reissued fairly frequently, it will be tempting
to generate them automatically from an on-line agent (daily CRLs seem
reasonable, but who wants to work on the weekend?).
A solution to this problem is to have multiple keys for the CA, where
one key is used only for certificate generation and the other(s) are
for functions that require higher standards of availability. The most
straightforward way to integrate this into our architecture would be to
have the CA issue certificates for the "lesser" keys and give them
reserved names. Signed messages of the lesser authorities could be
passed around with the certificates for those keys.
It's probably too late to fix CRLs (or is it?). But we should make
sure we do some such thing for any "new" functions we give to CAs.
--Charlie
(kaufman(_at_)zk3(_dot_)dec(_dot_)com)