I do not see much of any problem with delta CRL. A CA can communicate current revocation information as complete or as incremental.
It is up to the relying parties and the CP/CPS to determine how current the revocation information needs to be.
Delta CRL is good mechanism. It makes lot of engineering sense. If a CA or CP/CPS wants all relying parties to use information as of certain time, they can do so by issuing CRLs and/or delta CRLs at define times.
-----Original Message-----
From: Phillip Hallam-Baker [mailto:pbaker@xxxxxxxxxxxx]
Sent: Friday, June 15, 2001 12:36 PM
To: 'Denis Pinkas'; Manger, James H
Cc: ietf-pkix@xxxxxxx
Subject: RE: delta CRLs - NR assumptions
> I see a problem here. If you use delta-CRls,
I see lots of problems if you use delta CRLs. A veritable sea of troubles
bringing waves of misery and destruction upon an unhappy world.
If you want to ban anything to prevent this woe, then ban delta CRLs, this
solution would have the considerable advantage of reducing the size of the
RFC by several dead trees.
It is simply not possible to ban emergency CRLs. Nor do I accept the premise
that consistency is more desirable than correct answers. If an OCSP service
reacts on the basis of continuously updated real time data then it will
inevitably give answers that are different (i.e. right more often) to those
that an application relying on stale CRL data will give. Call such behaviour
'inconsistent' if you like.
Phill