Re: Major comments on OCSP (and LDAP Sec

[Ambarish Malpani <ambarish@xxxxxxxxxxxx>]

Hi Carlisle,
              Thanks for, once again, clarifying your position on OCSP. 

Yes, in principle, it is possible for you to configure CDP to create
mini-CRLs with a resolution of a single or no revoked certificate in
every
CDP.  And yes, you can issue that every 30 seconds if you want to.
(Ofcourse, all your CA will spend all day doing is issuing up to date
CDPs,
but that is your prerogative).

For the general audience, here is how I'd sum up the distinction between
CDP and OCSP : 

A. CDPs are a way for a CA to pre-compute and keep responses for all
possible certs it has issued, put them in the LDAP directory and rely on
LDAP to propogate them. (or you could make them accessible via HTTP/ftp
if
you wanted to, I suppose).

B. OCSP is a method that can be used to respond to queries as they come
in
and doesn't require people to set up LDAP for distributing its data. 

Each method has its advantages and disadvantages. 

I suspect people will want to use whatever serves their needs the best
and
leverages their existing investments and expertise.  For example, if
you're
comfortable with LDAP replication, have made the investment in an LDAP
infrastructure and expertise, like the pricing and have the expertise
around LDAP integration then you may be favorably inclined to CDP.

More comments follow below.

Carlisle Adams wrote:
> 
> 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.

Carlisle, I assume you don't really think any CA is going to carve
up CDPs into 1 entry per CDP. It would help compare the two
protocols if we actually came up with numbers indicating how
people actually divide up their CDPs and what normal/max CDP
sizes actually are.
CDPs of size 1 will not scale very well - they will require a CA
to perform a very, very large number of signatures and require
and enormous amount of storage in the LDAP server.

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

Are people actually combining delta CRLs with CDPs? I know you can,
but is anybody really doing that? Also, what is the resolution
people are using to issue CRLs, delta CRLs and CDPs?

> 
> > 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 statement made by Graham is still correct - it is quite possible
for an OCSP responder to give you up to date information if it
works off the CA's database.

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

But they may be...

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

Agreed.

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

Depends on whether you trust a whole bunch of CAs or just one or
two and whether that CA(s) you trust actually have a hierarchy
of CAs. Also depends on whether you get a lot of locality of
reference with respect to certs from a single CA. Caching the
CRL/CDP will work well for some cases and not for others.


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

Again, it depends on how many CAs you deal with and how many CRLs
you are willing to cache.

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

Actually, you might just need to connect to a single OCSP server,
because that server might cache revocation data from the
relevant CAs.

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

Am still waiting for that 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.

Hopefully this isn't a complete misconception :-)

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

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					         650.567.5457
ValiCert, Inc.				        ambarish@valicert.com
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833