Tom,
I think Steve's point is that the level of trust in that part of the PCA
that does CRL retrieval can be MUCH less than in the part that actually
creates (signs) CRLs and certificates. CRLs (and certificates) can be held
in an relatively untrusted repository (like the "ubiquitous" X.500 directory
or DNS or some similar database server); the trust is provided by the CA's
signature on the CRL. So the size of the trusted computing base can be
smaller for the CA than for a KDC. Co-locating the CRL retrieval service
with the PCAs is merely an implementation decision by PEM, to accommodate
the lack of ubiquitous directories and simplify the certificate management
architecture.
As to your comments on the complexity of the message flow for secret key
and public key architectures, I'd certainly agree that the number of
interactions is about the same if you retrieve the latest CRL for every
received message. On the other hand, one can also take the risk of *not*
retrieving the CRL on every message, which one cannot do in the KDC case.
Even the (fast becoming notorious) X9F1 standards don't require CRL
retrieval on every message. We do, on the other hand, maintain a CRL
sequence number so users can tell when a CRL was issued prior to the
nextUpdate time in the previous CRL. (This was, come to think of it, a
Steve Kent suggestion.) We also attach a reason code to each CRL entry,
since the actions to be taken may depend on whether the revocation is
due to, e.g., key compromise vs. change in organizational affiliation.
Regards,
Rich