Re: Two questions on delta-CRL

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxxxxxxxxxxx>]

It is not true that an application would need to retrieve multiple
deltas to resync.

Each delta CRL specifies the base against which it was issued.  A CA
could choose the scheme you describe where each delta is from the
previous delta.  But a CA could also choose a scheme where each delta
is from the previous base.  In the latter scheme, an application which had
lost its revocation information (or been offline for a month) would
have to obtain the daily full CRL and a single delta CRL.

As Sharon has pointed out, there is NO requirement in either X.509-2000
or X.509-1997 to publish a complete CRL when a delta is published.  To the 
contrary:

  "Depending on the policy of the responsible authority, several
  dCRLs may be published before a new base CRL is published."

                 -- X.509-2000, section 8.5.2.5, CRL scope extension
  
and

  "Note - it is the decision of the CA as to whether or not to distribute
  the CRLs issued between two base CRLs."
  
                 -- X.509-1997, section 12.6.3.3, Delta CRL indicator field



Draft-ietf-pkix-new-part1-01 says that a conforming CA MUST *issue*
a complete CRL for every delta, but it does not say that the issued
full CRL must be published anywhere except to /dev/null.  Note that
neither of the two suggested ways a PKIX application can construct
a complete CRL from deltas involves retrieving a current full CRL. 
(There are technical reasons for requiring only a single "revocation
state" to exist at any moment in time, and locally constructing a full
CRL is one means of capturing that state.)

I strongly disagree with any suggestion that PKIX requirements for base
CRL publication should be more restrictive than X.509's.  And I agree
that new-part-1 should make it clear that "issuing" a full CRL for
every delta does not *in any way* require publishing that full CRL.

Regards,
Dave



> From: Michael Ströder <michael@xxxxxxxxxxxx>
> 
> Sam Schaen wrote:
> > 
> > I believe the requirement for issuing a complete CRL when a delta CRL is
> > released makes sense.
> > [..]
> > The availability of a current full CRL also allows an application to
> > resynchronize at any point.
> 
> I think this is the most important argument. An application might
> loose the stored CRL or the CRL got corrupt by e.g. a system crash.
> The damage for the application is limited to the loss of some
> network-bandwidth. Resynchronization is simple.
> 
> E.g. if you issue a full CRL each day (24h) and delta-CRLs every
> hour the application will have to obtain the last full CRL and every
> delta CRL issued since then to get up to date (max. 24 accesses
> instead of one).
> 
> If you want to relax the requirement of issuing full and delta CRLs
> at the same time you have to mandate
> 1. that the CRL issuer stores all delta URLs from the last full CRL
> and
> 2. you have to provide appropriate service access points to obtain
> all necessary delta CRLs.
> 
> The application logic gets more complicated though.
> 
> Ciao, Michael.