I was just thinking about the scope of CRL distribution problem.
Let's assume that a given PCA grows to the point of having a million
(1,000,000) users, that the duration of a certificate is 12 months but
because of overlap they are issued every 10 months, and that the
average length time an individual stays in one job is 5 years.
(Actually, considering internal moves, promotions, etc., the time is
probably closer to 3 years, but I'll assume that these types of changes
do not involve emergency CRLs, and may not require revoking a certificate
at all.)
If the average length of time at a job is 5 years, then 20% of the users
will have their certificates revoked prior to their certificates expiring, but
only 2% (20,000) would be revoked in a given month. Assuming 25 days
per month, an average of 800 certificates would be revoked per day.
Because the major component of a CRL is the list of the individual
certificates that are revoked, and that is dominated by the length of the
issuer name, lets assume that the length of a CRL is approximately 50*N
bytes, where N is the number of revoked certificates.
Although 20% of the users would be expected to have their certificates
revoked before they expire, on the average only 10% of the users will
be listed in a given CRL. (The other 10% won't have expired yet.)
Again assuming 1,000,000 users per PCA, we would have 50*100000 or
5 megabytes per CRL. Even if only 10% of the users requesed an individual
update on a daily basis, that would be 500 gigabytes per day of CRLs flowing
out of that one PCA.
(But hey, GTE is in the communications business. What am I complaining
about? If we assume that traffic is spread over a 12 hour period, effectively,
that's only 92 megabits per second. A hundred T1 lines should handle it, no
sweat! Of course I don't know what it will do to the nearest switch's
performance -- might degrade it slightly.)
Suppose we were to take a slightly more rational approach, such as
distributing a baseline CRL once a month and only distributing the changes
to that baseline on a daily basis. Now we have a 5 megabyte CRL that can
be distributed by a NEWS type flood mechanism, perhaps, plus 0 to 10,000
certificates revoked during the month.
If all the CAs (or distributed X.500 directories or whatever) could be counted
on to reliably receive each daily update, then we would only have to transmit
about 5K bytes per day from the PCA through the flood-type mechanism.
Otherwise, the daily CRL update list would grow from 0 to 100K bytes,
then drop back to zero again. This would obviously be a much more robust
and fail-safe mechanism, as the daily update could be chained back to the
monthly update.
An intermediate compromise might be to distribute a weekly CRL baseline,
perhaps on Sunday when the network is relatively underutilized, plus a
daily update. The baseline CRL would still be on the order of 5 megabytes
but the daily update list would only grow to about 25K bytes. This
is now beginning to be somewhat more reasonable.
Now those users who are not involved in financial or other transactions
may not even need to retrieve the daily updates -- the weekly might be
sufficient.
Unfortunately, in order to support nonrepudiation, we still have to archive
the baseline plus the daily updates. We clearly can't archive a 5 megabyte
CRL with every document or message, so we have to have a way of
efficiently and securely storing and retrieving the CRL database. Assuming
that the incidence of questioned documents is quite low, it would seem that
a WORM optical disk would be suitable. Perhaps as much as a year's worth
of CRLs could be stored on a 2 gigabyte disk.
Now suppose we took the alternative of having a positive file, rather than
a negative file. Let's assume that each user corresponds with 10 other
users per day where either digital signatures or encryption would be
important. If each response were signed, this would amount to 10 million
responses of about 500 to 1000 bytes each, or about 10 gigabytes per day.
Although this is significantly better than the 500 gigabytes required if every
user were to request a complete current CRL every day, it is way too much
overhead for routine transactions. I therefore conclude that the distribution
of
a weekly negative file plus daily updates is probably the best way of
handling the revokation problem within a given PCA's domain.
But what about cross-domain certification and revocation? The RFCs say
(but I haven't heard any PCA yet agree to take on this function) that each
PCA is supposed to forward their CRLs to the IPRA, and eah PCA should
make available all of the CRLs from all of the various PCAs to their users.
My guess woiuld be that there may eventually be 100 or more PCAs,
considering all of the various policies in each country and the likelihood
that each country will have its own set of PCAs for each different type
of policy. Not all of these PCAs will attract the same number of users,
obviously, but the total number of users might easily grow to 50 million
worldwide over the next 5 years.
Clearly if 1 million users caused all sorts of problems of scale, 50 million
users will be far worse. Yet in most cases only a very small percentage
of users will actually be communicating across PCA domains. It therefore
seems VERY undesirable to (re-)distribute all of the CRLs from all of the PCAs
via a "push" type of type of mechanism. It would therefore seem reasonable
for a PCA to provide a linkage to the "other" PCA, and for the user's request
for validity checking to go directly to that other PCA for signing of a
positive
response, rather than returning a negative indication of a huge number
of CRLs that don't apply. I don't think I would necessarily trust my PCA to
digitally sign a positive validation for a user within another PCAs' domain,
but I might trust that other PCA to sign for his users and CAs.
More thought is required, but are we getting somewhere?
Bob