Re: [IETF-PKIX] OCSP Current Status

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

>From: Michael Myers <mmyers@verisign.com>
>
> >From: Paul Hoffman / IMC <paulh@imc.org>
> >
> > True, but I think that this argument argues even more strongly for the
> > removal
> > of marketing words like "efficiently and rapidly" and "timely" from the
> > spec.
>
> We probably have a wordsmithing problem if that's the case since we need to
> state the existence of the timeliness requirement.  OCSP owes its existence
> to this requirement.  My point being that this draft is not a design spec
> intending to constrain implementors so as to ensure they develop products
> that will deliver timely service.


There certainly is a timeliness requirement.  OCSP has been proposed
and advertised as a solution that can satisfy that requirement,
whereas others have expressed skepticism backed up by preliminary
analysis indicating that OCSP alone is not a scalable solution, and
that CRLs fetched in online queries would present far less computational
and communication burden on a large CA than would OCSP.

The wordsmithed text must either describe where in a system
architecture OCSP is suited for use and where it is less well suited,
or it must confine itself to technical interoperability
specifications only and make no advertising claims about timeliness.

Entrust has proposed a timely revocation solution based on CRLs using
the patented crlDistributionPoint method.  I believe that an equally
efficient and more dynamically adjustable solution can be
constructed using online queries for non-patented delta-CRLs over a
monolithic subscriber base.  Both of these methods may use OCSP
for the final end-user to local-status-server link, but OCSP is
useless without a method for efficiently distributing timely
status information away from the CA.