RE: Major comments on OCSP (and LDAP Sec

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

Actually I dont have a misunderstanding - I read the spec.
I just believe that I dont build a large scale system for operational
use - with a mechanism, that does not scale, does not have an
information and processing model (and the way that relates to the whole
of the system), does not define operational parameters, cost and human
management.. thats all ..  its my preference.

OCSP is a "mechanism" with flaws and no system model to really work to.

In customer eyes that relies on big systems - that is risk.

thats all.

regards humble alan 

----------
From: Carlisle Adams
To: Alan.Lloyd@OpenDirectory.com.au; 'Graham Bland'
Cc: ietf-pkix@imc.org
Sent: 8/12/98 1:09:47 AM
Subject: RE: Major comments on OCSP (and LDAP Sec

Hi Graham,

There are a number of misunderstandings surrounding OCSP.  Perhaps this
exchange serves as a good opportunity to try to clear them up once
again.

> ----------
> From: 	Graham Bland[SMTP:gbland@zergo.com]
> Sent: 	Tuesday, August 11, 1998 6:14 AM
> To: 	Alan.Lloyd@OpenDirectory.com.au
> Cc: 	ietf-pkix@imc.org
> Subject: 	RE: Major comments on OCSP (and LDAP Sec
> 
> Let me try and define the purposes and use of OCSP from my
perspective.
> 
> If you feel it appropriate could you please post this on to the  ldap
ext
> list.
> 
> Over a period of time a CA will receive revocation requests for
> certificates 
> for a variety of reasons from a change in status or name to a
compromise
> of 
> the keys.
> Periodically it publishes the information on all revoked certificates
in
> CRLs.
> These CRLs will be fairly large and there is a time lag between the 
> revocation of a certificate and its appearance on a CRL.
> 
Size is not really the issue.  Distribution points allow the CA to carve
up
the CRL into pieces of any appropriate size (even size 1, if this is
desired
for some reason).  The time lag is the issue.

> If I am using a certificate chain to authenticate a high value
transaction
> 
> this delay is unacceptable.  For practical reasons of distribution and
> their 
> potential size CRLs are unlikely to be published more than daily at
the 
> most, Delta CRLs solve some of this problem but even if we postulate
60 
> minutes as the generation period this still leaves a potential 60
minute 
> gap.
> 
Delta CRLs do not solve "some of this problem".  They solve as much of
this
problem as desired, up to and including "all of this problem".  If a CA
is
operated in a domain where delay is unacceptable, delta CRLs can be
published every 5 minutes, or every minute, or every 30 seconds, or
whatever.  Absolutely any interval can be chosen to meet the needs of
the
environment.  Delta CRLs allow timely revocation information for any
definition of "timely" and, as a bonus, typically have low bandwidth
requirements since they carry only the revocations that occurred since
the
last full CRL was published.

> An OCSP Responder may be closely coupled to a CA and trusted to access
the
> 
> CA database, it therefore has access to the revocation status of a 
> certificate as it stands at this moment in time, there is no
distribution 
> gap.  So it can return a more timely revocation status of a
certificate
> (Not 
> the certificate itself) to a Client.
> 
Be sure to note the fourth word in the first sentence:  an OCSP
responder
*may* have this coupling to a CA.  It also may not.  There is nothing in
the
OCSP protocol to guarantee timely revocation status.  Period.  It is
perfectly legitimate for an OCSP responder to be working *only* from
published CRLs (in fact, people on this list recently have stated that
allowing this is an important requirement of this protocol), in which
case
the OCSP response is no more timely than the CRL itself.

> The other use of an OCSP Responder can be to provide the status
> information 
> for other CAs by accessing the CRLs for those CAs.  This approach
removes 
> the requirement for every end user to:
> Retrieve multiple large CRLs
> 
Again, they need not be large...

> Verify the CRLs
> 
Verifying CRLs is not more difficult or more time consuming than
verifying
OCSP responses...

> Store in an accessible form the list of revoked certificates (required
to 
> prevent having to re read the CRLs for every transaction)
> 
Actually, this is a "feature", not a "bug".  Having revocation
information
about many certificates locally means that for your next several
transactions you may not need to go out to the network.  With OCSP you
always make a network call for every certificate you want to check (and
sit
there waiting until you get a response or until you time out).

> Practically in e-mail systems CRLs cannot be retrieved and processed
on 
> demand when required by a transaction.
> 
I know of no systems (actual or proposed) that go out to retrieve a full
CRL
with every transaction.  CRLs are cached locally until the end of their
validity period.  If you need the freshest possible information, you go
out
to get a delta.  OCSP forces you to make a network connection every
time.

> Assume I am sat at my PC and have a certificate of an end user to whom
I 
> wish to secure an Email.  I must retrieve the CRL to validate the 
> certificate path from my CA to their CA, assuming this requires CRLs
from
> 4 
> CAs I may need to process well over 1 Mb of data depending on the
number
> of 
> certificates issued by the CA and the number of revoked certificates. 
> Depending on the bandwidth I have to the LDAP servers this will
probably 
> take too long to leave the user waiting.  4 OCSP requests will be a
lot 
> quicker.
> 
Note that it is possible to avoid this situation using Indirect CRLs
(depending upon how the environment is set up and upon the agreements
between the CAs).  In any case, 4 OCSP requests will be a lot quicker
than
what you describe, but will *not* be a lot quicker than retrieving 4
delta
CRLs.

> Secondly the Directory may not exist. If an organization has its own
CA
> this 
> does not imply that they also have a Directory server or access to
one.
> 
Agreed, the Directory may not exist.  However, some sort of repository
must
exist somewhere in the organization (otherwise every single entity would
have to store the certificates of every other entity in order to make
full
communication possible).  The repository is a necessity (and for some
environments, the Directory is simply a convenient, full-featured
repository).  CRLs (and delta CRLs) will be stored in this repository.

> Your detailed comments follow
> 
> 
> > I skipped the rest I am afraid.
> >
> >I have assumed that this proposal has been developed because of the
> >fundamental issue with non distributed LDAP servers in that they
cannot
> >do mutual authentication between servers (no distributed User trust)
and
> >they cannot do distributed cert path or crl processing.
> >
> 
> Wrong assumption I am afraid.  Timeliness of revocation information is
the
> 
> main driving force.
> 
If timeliness of revocation information is the main driving force, then
don't rely upon OCSP (because it is not guaranteed to provide this).
This
is a complete misconception.


--------------------------------------------
Carlisle Adams
Entrust Technologies
cadams@entrust.com
--------------------------------------------