Anish,
In a message you sent in late September, you suggested that a
socket-based (real-time) CRL retrieval service might be useful. I
agree, but wish to expand to your observation about the problem of
firewalls. We have designed PEM ancillary services to all be
accessible via email not only to avoid firewall problems but also
to avoid disenfranchising users whose only communication path is
email. While it is reasonable to consider additional access paths
for PEm-related services, I think we should require email-based
access for all such services as a baseline.
Your observation about the problem of verifying the timeliness of
a CRL retrieved from a repository is valid and that is a major
reason why the next issue date is included in PEM CRLs (vs. 88
X.500 CRLs). The inclusion of this field bounds the lifetime of
undetectable replays. Any retrieval mechanism involving a
potentially untrusted repository has a form of replay problem. If
one employs a trusted repository and a protocol that involves
active security measures by both the accessor and the repository,
then replays can be thwarted, but that creates the sort of
problems that Charlie Kaufman alluded to in his message, i.e., a
need for a CA/PCA to employ its key (or a related key) to sign a
real-time response.
You raised the question of whether CA should distribute CRLs to
avoid possible charges by PCAs for CRL retrieval. Well, nothing
in principle prevents a PCA for charging for CRL retrieval, but
that was not the model envisioned when we required PCAs to provide
access to a global CRL database. In fact, the intent is that the
IPRA actually operates the database and the PCAs just provide well
known access points for the PEM user community. (As noted
elsewhere, this is intended as an interim measure until more
global directory access is available.)
We did envision a CA redistributing CRLs (not just its own) to
local users, but that is very different from having a CA be
contacted by any user wishing the CRL issued by that CA. As I
mentioned in my response to Bob and Sead last week, one immediate
problem with CAs providing CRL services to other than local users
is the problem of mapping a CA's DN into a mailbox name. Also, if
users go directly to each CA from which they require a CRL, this
creates much more traffic than if users make compound queries to
an access point to a comprehensive CRL database. From an
availability standpoint, it also may be easier (and more
economical) for the IPRA and PCAs to provide a replicated
comprehensive CRL database, than to require each CA to offer high
availability CRL retrieval service.
Steve