[IETF-PKIX] OCSP v CRLs over HTTP

[Tim Moses <tim.moses@xxxxxxxxxxx>]

Colleagues - I have been reviewing the OCSP and the 'FTP and HTTP'
drafts, and it occurs to me that OCSP can be considered to be a special
case of the latter scheme.  This would not be the case if OCSP could
offer a 'live' response in a large-scale system, but clearly this is not
practical.

I assume that OCSP is designed to provide notification of revocation
over the Internet in the absence of a replicated directory.  Clearly,
there is a need to solve this problem.  But the use of CRLs over HTTP
offers a more general solution to the same problem.  In addition, it is
a more robust solution, offers greater flexibility in engineering
implementations, exhibits lower cost and makes better re-use of existing
software.  HTTP-caching must be used with either protocol, in order to
achieve adequate scalability.  In which case, the CA can control the
cache retention interval in intermediate HTTP servers, in order to
ensure that they will be refreshed when new revocation status
information is scheduled to become available.

An illustrative example to support these conclusions is provided at the
end.

Summary

OCSP places a heavy load on the most highly shared components of the
system, making it unnecessarily expensive to offer a scaleable and
compliant service.  This is because dividing revocation information into
its smallest parts makes the probability of a cache hit in the periphery
of the network insignificant.  This may be appropriate if, for some
reason, one wants to ensure that each individual revocation status
request is serviced directly by the CA, but a more general solution is
required for situations where this is not a consideration.  Moreover,
the general solution can, if necessary, be engineered to provide a
service equivalent to that offered by OCSP where this is appropriate.

Conclusions

OCSP and the 'single monolithic CRL for the entire subscriber-base'
approaches represent two extremes of the general solution represented by
CRL distribution points accessed over the HTTP infrastructure.  OCSP can
be considered equivalent to assignment of a single subscriber to each
distribution point, and the single monolithic CRL can be considered
equivalent to the assignment of the entire subscriber-base to a single
distribution point.

The special case of OCSP leads to a solution which minimizes the
consumption of network resource in the dedicated data-link between the
relying party and its ISP.  But, this is not a scarce resource (largely
because it is not shared).  The penalty paid for this is that there is
increased demand placed on the most highly shared components (the
data-link between the Internet and the CA and the CA's signature
facility).  This leads to excessive hardware and communication costs.

Using CRLs over HTTP represents the general solution of which the other
two can be considered special cases.  Therefore, each implementation of
the general case can be engineered, as appropriate, to satisfy the
requirements of the specific application.  Those for whom the
characteristics of OCSP are attractive may tailor the general solution
to recreate OCSP-like characteristics.  Others can make different
choices, without having to modify the operation of the relying party
software.

So, I propose that we examine the Internet Draft protocol for
distributing CRLs over HTTP and ensure that it adequately accommodates
the concerns that led to the proposal for the OCSP protocol.

Analysis

The effect of caching at the periphery of the Internet becomes apparent
by considering this illustrative example.

The architecture consists of ten components connected linearly in order
from 1 to 10.

Component 1: The relying party.
Component 2: The relying party's HTTP cache.
Component 3: The relying party's data-link to its ISP.
Component 4: The ISP (let's assume that each ISP serves 1,000 relying
parties).
Component 5: The ISP's HTTP cache.
Component 6: The ISP's data-link to the Internet backbone.
Component 7: The Internet (let's assume that all the relying parties are
represented by 1,000 ISPs).
Component 8: The data-link connecting the Internet backbone to the CA.
Component 9: The CA's HTTP cache.
Component 10: The CA's signature facility.

In this architecture, the CA serves 1 million subscribers and 1 million
relying parties, via 1,000 ISPs.

Other assumptions we need are these.

Assumption 1.  Each use of the OCSP protocol consumes 6 kilobits of
network resource.  This number includes the signature on the OCSP
response (assumed to be 1024b or 170 base64 characters), but it also
includes bits associated with establishing and destroying a TCP
connection and sending the HTTP message.

Assumption 2.  In the case of CRLs over HTTP, let's assume that the 1
million subscribers are assigned to 500 distribution points, and that
10% of subscribers are revoked at all times.  This situation might
obtain in a corporate setting, where certificates are issued with a one
year validity, they are revoked when the holder leaves the corporation
and the corporation suffers a 10% staff turnover.  I believe these are
very conservative assumptions.  Under these assumptions, the network
resource consumed by retrieving a distribution point entry may be 50kb,
including the bits associated with the connection and message.  While
this number is almost ten times that for OCSP, it is much more
efficient, because it conveys information about 2,000 certificates.

Assumption 3.  Each relying party validates 0.01 certificates per second
during the "busy-hour" (this pattern of behavior  is consistent with use
for signed and encrypted email, in which all relying parties work
through their "overnight" email first thing in the morning).

Assumption 4.  The relying parties are spread geographically over three
time zones.

Assumption 5.  In order to keep delays caused by contention for shared
resources to an acceptable level, shared components will be engineered
with a capacity three times the calculated busy-hour average demand.

In the case of the OCSP protocol …

OCSP component 2 (relying party HTTP cache).  The probability of a hit
on the relying party's cache is zero.

OCSP component 3 (relying party data-link).  The average resource
consumption in the data-link between the relying party and the ISP is
6kb * 0.01 per sec = 60b/s.

OCSP component 5 (ISP HTTP cache).  The probability of a hit on the
ISP's cache is essentially zero (the ISP receives 36,000 requests during
the busy-hour.  If you pick at random, from 1 million items, 36,000
times (replacing them after each pick), then the probability of picking
the same item twice is negligible).

OCSP component 6 (ISP data-link).  Each ISP passes 36,000 requests per
hour to the Internet backbone.  So, the resource consumed in the
data-link between the ISP and the Internet backbone is 1,000 * 60b/s =
60kb/s.  Applying Assumption 5, a 256kb/s data link is required.

OCSP component 8 (CA data-link).  If the ISPs each serve one time zone,
then 333 of them will be generating busy-hour traffic levels at the same
time.  Therefore, resource consumption in the data-link between the
Internet and the CA will be 333 * 60kb/s = 20Mb/s.  So again, by
Assumption 5, a 60Mb/s ATM link is required.

OCSP component 9 (CA HTTP cache).  The CA's cache outputs is 36,000 *
333 = 12 million requests per hour.  So, a database capable of serving
3,333 read operations per second is required.

OCSP component 10 (CA signature facility).  If the CA takes 3 hours to
replenish its cache with a new entry for each of its 1 million
subscribers, then the CA's signature facility must support a rate of 90
signatures per second, and responses may be up to three hours out of
date.

In the case of the CRLs over HTTP protocol. …

CRLs over HTTP component 2 (relying party HTTP cache).  The probability
of a hit on the relying party's cache is zero.

CRLs over HTTP component 3 (relying party data-link).  The average
resource consumption in the data-link between the relying party and the
ISP is 50kb * 0.01 per sec = 500b/s.

CRLs over HTTP component 5 (ISP HTTP Cache).  The ISP's HTTP cache
receives 36,000 requests per hour for one of 500 distribution points.
Therefore, the probability of a cache hit is 0.986.  Although each
request consumes about ten times as much network resource, only slightly
more than one in every hundred requests are transferred to the Internet.
 So the amount of Internet traffic generated is approximately one tenth.

CRLs over HTTP component 6 (ISP data-link). The average data rate
transferred by the ISP cache to the Internet is the number of relying
parties times the average data rate per relying party times one minus
the efficiency of the case.  I.e. 1,000 * 500 * (1 - 0.986) b/s.= 7
kb/s.  Therefore, by Assumption 5, a 32kb/s link would be adequate
between the ISP and the Internet backbone.

CRLs over HTTP component 8 (CA data-link).  If the ISPs each serve one
time zone, then 333 of them will be generating busy-hour traffic levels
at the same time.  Therefore, resource consumption in the data-link
between the Internet and the CA will be 333 * 7 kb/s = 2.3 Mb/s.  So, by
Assumption 5, a 7Mb/s data link is required between the Internet and the
CA.

CRLs over HTTP component 9 (CA HTTP cache).  The CA's cache receives 333
* 500 requests per hour.   So, a database capable of servicing 50 read
operations per second is required.

CRLs over HTTP component 10 (CA signature facility).  If the CA were
capable of performing 90 signature operations per second, then
theoretically, it could update all of its 500 entries once every six
seconds.  If, however, it were to update them every three hours, then
its signature capacity must be 0.04 signatures per second.


--------------------------------------------------------------
Tim Moses, Entrust Technologies,
Tel: 613 247 3183,
email: tim.moses@entrust.com.