RE: Major comments on OCSP (and LDAP Sec

[Carlisle Adams <carlisle.adams@xxxxxxxxxxx>]

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
--------------------------------------------