[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: delta-CRLs and NR



     When non-repudiation is an actual practice, doesn't the revocation
status need to be checked as of a time no earlier than the actual signature
of the non-repudiable message or document?  And won't a full CRL (or a
delta, for that matter) rarely have been published with such an effective
time at the time an RP initially receives such a message or document?
     It is perfectly true that it is much easier to check a single full CRL
than a CRL with deltas.  However, I don't see why the problem is more
severe for NR except that an NR system is even less tolerant of false
negatives on revocation than authentication is.

          Tom Gindin


"Michael Myers" <myers@xxxxxxxxxxxxx> on 04/23/2001 02:30:39 PM

To:   "David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>, <ietf-pkix@xxxxxxx>
cc:
Subject:  RE: delta-CRLs (was Re: LastCall:draft-ietf-pkix-new-part1-06.txt
      comments)


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.