Re: Two questions on delta-CRL

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

David,

Thanks for paying interest to this topic.
 
> 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.

I have difficulties to understand your last sentence, since the text says:
"When a delta-CRL is issued, the CAs MUST also issue a complete CRL".

> If a base CRL is re-published at the same interval as the dCRL, the value of
> dCRLs diminishes 

Agreed.

> as the cost and latency of base CRL publication is much
> higher for the network.

Denis

> 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