[caops-wg] OCSP section 6.3
Mike Helm
helm at fionn.es.net
Fri Jun 3 20:33:32 CDT 2005
Olle Mulmo writes:
> On Jun 3, 2005, at 08:38, Olle Mulmo wrote:
>
> >
> > t0: CA operator presses the "revoke" button
> > t1: CRL gets timestamped
> > t2: CRL gets published
> > t3: CRL is fetched /pushed over to OCSP responder
> > t4: OCSP responder has updated its revocation database
>
> Of course, t4 may not necessarily be associated with t1,t2,t3 in the
> general case. In fact, t4<t1 would be possible in some scenarios (the
> OCSP responder reading directly from the CA database).
What about this tack.
>From my point of view, the message I want to get out in this document
includes "OCSP can get you real time revocation information!"
That really means, we can make a better real time approximation
than CRL's.
So 6.3 should describe how we could do that. That's what I think it
is trying to do. It may be doing something else too, but that's all
I read into it. Here's my "mock" re-write of this section:
A certificate can be revoked, but information about this revocation
can take a considerable amount of time to reach a relying party:
forever, if CRL's or OCSP checking is not available; at least 24 hours
and often many days in typical Grids today; perhaps an hour or more
in typical OCSP responders and CRL generation systems in use today.
Delays in propagating revocation info longer than a few hours are
unacceptable to most security professionals. Currently, most CA's
produce CRLs that are only published on their public repositories.
OCSP responders and other consumers of CRLs must periodically poll
this repository and download new CRLs. A CRL for a large CA
may be quite large and downloading a complete list may take a long
time.
We recommend that Grid CA's produce a CRL whenever a revocation takes
place. Since this can be quite burdensome on the CA and on the
consumer we recommend that large CA's produce delta CRL's
[RFC 3280 5.2.4 p 55] as well as full CRL's. We recommend that
CAs adopt a _push_ model for CRLs and publish directly to the OCSP
service, where possible. OCSP server developers and deployers should
plan for this configuration [or something].
What do you all think of this? Is it compatible with what you want to do?
What else needs to be said?
More information about the caops-wg
mailing list