Subject: Re: Huge CRLs

From: [email-masked]
Date: Tue, 14 Sep 1999 00:15:51 EDT

Steve,

I freely acknowlege the fact that I am biased because of my experience, 
sector focus, and sunk costs.   I did not intend to defame or diss anyone or 
their ideas.  Some financial services applications may have requirements and 
profiles that are unique, but I believe that in many cases the early lessons 
learned by the financial services sector will be required reading for others 
who are trying to scale up their systems or engage in high value transactions.

I have tons of reasons for wanting to see revocation issues addressed to the 
satisfaction of a pretty demanding set of customers in the financial services 
sector.    Almost everyone already knows by now that I am working on CRL 
alternatives and have both policy, personal, and economic interests in this 
issue.  What has bothered me for quite some time is that despite everyone's 
best efforts, PKI technology has so far fallen short of delivering on its 
promises and underreturned on investments in part because of inflexible 
technology and models.  Even the most immature solutions have a lot of merit 
and are producing risk reduction results, but it has been extraordinarily 
difficult to integrate PKI into traditional entities production systems 
because of the inflexibility of many models and technologies.  I find more 
potential within PKI to transform business (strategy, policy)  models and 
processes than even TCPIP, but the practical work of infrastructure (legal, 
technical) development is painful.  A lot of effort and other resources are 
being invested and progress is being made.  I have committed significant 
personal resources to support my previous investments in PKI policy, and 
technology.    Much of my time is focused on defining the policy space (law, 
regulation, standards); helping people and institutions understand the policy 
space, business requirements, and technology; and providing technology 
solutions to fill gaps.

I have been working on Federal digital signature legislation for four years 
and believe that we will get another bill this year.  I can only hope that 
the technical infrastructure will be sufficiently robust when the legal 
infrastructure is made partly ready.  The technology and practitioners must 
deliver the goods as promised or the markets and governments will punish 
everyone however tangentially involved.

SPECIFICS

Sometimes certificates are used purely for comfort and possession of a 
certificate from a recognized issuer is acceptable as a superfeatherweight 
identification.  In this case revocation information is likely to be never 
sought and frequency is not a real concern.  In some cases systems do not 
support checking at all.  Many systems in pilot and production that have 
requirements for heavyweight authentication resemble the above pictures when 
subjected to close evaluation.   While this may be abhorrent to some minds, 
it is true that in practice, "effective revocation" is not an option for 
many.  In this case policy must be made to conform to the capability of the 
systems relied upon.  In the long run these suboptimal practices are 
unsatisfactory and unacceptable. Maturation will solve these problems.

In other cases, information must be a fresh as possible.   Recency 
specification between fifteen minutes to two hours are not uncommon policy 
driven requirements.   The transactional environments in the financial 
services sector can be split into wholesale (relatively few participants, 
uncountable dollars, many transactions) and retail (the population, huge 
dollars in total, uncountable transactions.)   Today it is easier by far for 
PKI to meet the requirements of the superfeatherweight and wholesale 
segments, than the retail segment because of gaps between business 
requirements and practical technological capability.  The liability exposures 
and allocation models the banking and securities industry must face present 
tremendous challenges to PKI solutions and practitioners.

Look at the following two extremes:

1.  A CRL is issued every day (or pick some other time period, say every 
week, or every two hours).  Users can go pick this up, and use it for a day 
without having to interact with the repository to get the CRL again.  This 
ignores a few points, for example - you don't want to jam things up when the 
CRL is issued by having everyone go retrieve it at once (Dave Cooper of NIST 
presented several papers on this at recent FPKI-TWG meetings).  (Business 
practices and policy requirements may cause this problem to occur in spades)

Also, different certificates may be issued by different CAs, and so will the 
CRLs, so
you might have to get several CRLs during the day.  (a near certainty) But
basically you have a list of revoked certs that's good for a day or two hours 
or whatever.  Of course, most of the entries on the list are ones you 
probably (almost certaintly) don't care about (depending on how many signed 
messages you get per day, and from whom), so there is "wasted" space and 
bandwidth for the revoked
certs which you don't care about (because you don't get any messages using 
those certs often or ever).

Correspondence not involving authorization of financial transactions or the 
disclosure of sensitive business information is an example of an acceptable 
use of a daily CRL.   Frequently issued CRLS from small scale PKI's are easy 
to implement and rational to support.   Huge frequently isssued CRLs from 
large scale PKIs are another thing altogether.

2.  At the opposite extreme, you could make an OCSP query every time you 
verify a signature.  This can be justified for wholesale transactions, but 
not for ordinary activities.   The response is small (on the order of several 
hundred to 1K bytes including signature of the OCSP responder), and contains 
just the info you want.  But now you are doing a realtime query every time 
you get a signed message, rather than one query for a CRL once a day.  And 
the responder has to sign each response, vs. the CA signing one CRL a day.
This is a serious performance issue.

So #1 and #2 are the two extremes.  Depending on your risk analysis, based on 
transaction volume, transaction  amount, traffic patterns (e.g. # of 
messages/day between two specific parties), bandwidth and storage 
constraints, and so forth, maybe one of these two extremes might be suitable. 
 But there are lots of things in the middle:

3.  If CRLs become large, you can partition them using the CRL distribution 
point mechanism; this handles, to some extent, the bandwidth and storage 
problems.

I have done this.

4.  Many small CRLs can be combined into one indirect
CRL.

I have done this.

5.  If you want more up-to-date information, without issuing a whole new CRL, 
you can use delta CRLs, issued (say) every two hours.  But now the user has 
to keep track of the full original CRL (which he had to do anyway, for one 
day), and apply the delta CRL contents (updates) to that CRL.   So the user 
software gets more complicated. 

I have asked people to do this for me.

6.  OCSP can also precompute responses (maybe driving off full and delta 
CRLs), so an OCSP response can be (using the above example) good for one day, 
two hours, or whatever. This eliminates the need to make an OCSP query for 
every
received message; the downside is you no longer have absolutely current 
results (of course this same downside occurs with all CRL-based mechanisms).  
But that's usually OK.

I have asked people to do this as well.

OR YOU CAN DO ALL OF THE ABOVE AND MORE!

I am focusing on the more part and trying to make the rest work where the 
solution can be made to fit the requirements.

There are other solutions that are not currently practiced and I am convinced 
that none of the solutions (above or unlisted) will emerge the undefeated 
champion of the PKI  revocation world because business requirements, public 
policy driven requirements, server, client, and other system capabilities 
will fail to converge.

Perhaps I should have said that CRLS are inadequate for many applications.

Respectfully,

(x)

...kawika daguio...

---

From: Stephen Kent <[email-masked]>
Date: Thu, 16 Sep 1999 11:14:56 -0400

Kawika,

>space, business requirements, and technology; and providing technology

I see a possible basis for divergence in our expectations here.  I think
that it is not necessarily appropriate to expect to transform all aspects
of doing business by introducing PKI-based systems.  For example, if you
say that a PKI-based system is inadequate unless two companies can execute
a multi-million dollar agreement, having never previously done business
with one another, purely in cyberspace, etc., then we disagree.  My
expectations are more modest.  I would be happy if we could take most
existing ways of doing business in the physical world and move them to
cyberspace.  The cost savings would be very substantial, as would the
increases in efficiency.  The notion of that we must create PKIs that
enable high value transactions to take place without reference to
traditional relationships in the physical world, has, in my opinion, done
more to retard the deployment of useful PKIs than any technical
limitations.  However, I may be misunderstanding the range of apps you're
alluding to above.

Steve