RE: delta-CRLs (was Re: LastCall:draft-ietf-pkix-new-part1-06.txt comments)

["Michael Myers" <myers@xxxxxxxxxxxxx>]

Dave,

But in a broader sense, isn't that precisely the problem directory
replication is all about?

It would be useful to hear of empirical studies establishing the extent to
which PKI information management today dominates directory (X.500, LDAP)
operations.  I advocate that we need to know what today's ground truth tells
us before we flip this parity bit; else wiggle the text as I proposed and so
provide everybody the tuning knobs they want to tailor the standard to local
needs.

More tactically, one could produce a full CRL as a "backup" but let the
delta practice take the burden of timeliness and bandwidth efficiency.  But
in all cases where non-repudiation becomes a true (vice theoretical) issue,
there MUST be a full CRL around somewhere that cleanly establishes a
context.  Else one is faced with reconstituting the full context via
re-accumulation of all the relevant deltas.  Not an easy task either, and
one prone to error.  Given the ease with which a full CRL can be produced
(assuming mechanisms are in place to produce deltas), just crontab two
periods:  a "full" production and a "delta" production, with the period of
the latter shorter than the former.  You don't have to push the full CRL all
over the place, but at a minimum certainly have it available.

A systems-level tradeoff, as always.  But dumping full CRLs entirely and
trusting deltas exclusively isn't something I'd advocate to any enterprise
concerned about its risk management practices.

Mike

> -----Original Message-----
> From: dpkemp@xxxxxxxxxxxxxxxxxxxxxxx
> . . .
> The problem is that once the full CRL is signed, it is transmitted across
> the network to directory/database/repository replicas and to clients.
> If you are a PKI provider (as I am), and you have to provision 3.5
> million subscribers, the cost of that provisioning with full CRLs is
> prohibitive, whereas the cost of provisioning with deltas is not.