[caops-wg] OCSP section 6.3

[Mike Helm]

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?