RE: Two questions on delta-CRL

[David Cross <dcross@xxxxxxxxxxxxx>]

I think the important distinction is to ensure that a valid base CRL always
exists.  A client 1) may not understand a dCRL or 2) a client may not
already have the base CRL that the dCRL is derived from.

The way I read the RFC is that a valid base CRL must exist when the dCRL is
published.  This does not necessarily mean that the base CRL must be
re-published every time a dCRL is published.

If a base CRL is re-published at the same interval as the dCRL, the value of
dCRLs diminishes as the cost and latency of base CRL publication is much
higher for the network. 

David B. Cross



-----Original Message-----
From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
Sent: Tuesday, January 02, 2001 6:37 AM
To: Sam Schaen
Cc: IETF-PXIX
Subject: Re: Two questions on delta-CRL


Sam,

Thanks for attempting to answer the question. One possible answer would be
to prevent people using delta-CRLs to get an advantage over people using
regular CRLs. The text used to write RFC 2459 was written at a time where
OCSP servers did not existed. However, clients now using OCSP servers may
get such an advantage, i.e. fresher information about revocation status. 

Would the following scenario (currently forbidden by RFC 2459) makes sense ?

The full CRL is issued every day, and a delta CRL is issued every hour. 

I was wondering whether it would be possible to relax this rule, and thus
have e.g.:

When a delta-CRL is issued, the CAs SHOULD also issue a complete CRL.

However, before doing so, we must understand the original rational and all
the implications. To understand the original rational I would expect a
response from one of the authors of RFC 2459. However, for the second part
of the question (i.e. all the implications) the discussion is open.

Denis

 
> I believe the requirement for issuing a complete CRL when a delta CRL is
> released makes sense.  It permits applications that don't understand delta
> CRLs to obtain the most recent information.  Overall network bandwidth
usage
> is still reduced to the extent that other delta-CRL-capable applications
do
> make use of the delta CRL rather than retrieving a full CRL.  The
> availability of a current full CRL also allows an application to
> resynchronize at any point.
> 
> Denis Pinkas wrote:
> 
> > In section 5.2.4 (Delta CRL Indicator), RFC 2459 states:
> >
> >   The delta CRL indicator is a critical CRL extension that identifies a
> >   delta-CRL.  The use of delta-CRLs can significantly improve
> >   processing time for applications which store revocation information
> >   in a format other than the CRL structure.  This allows changes to be
> >   added to the local database while ignoring unchanged information that
> >   is already in the local database.
> >
> >   When a delta-CRL is issued, the CAs MUST also issue a complete CRL.
> >
> >   (...) Again, a delta-CRL MUST NOT be issued without a corresponding
> >   complete CRL.
> >
> > The two questions are the following:
> >
> > 1) What is the rational for mandating the issuance of a complete CRL
each
> > time a delta-CRL is issued ?
> > 2) Under which conditions could this requirement be relaxed ?
> >
> > Denis