Re: [IETF-PKIX] OCSP v CRLs over HTTP

[Russ Housley <housley@xxxxxxxxxx>]

Tim:

the digital signature on the CRL returned by HTTP or FTP provides teh
authentication.  How is comperable authentication provided in the alternative?

Russ

At 09:17 AM 12/2/97 -0500, you wrote:
>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.
>