Subject: Re: Two questions on delta-CRL

From: "David P. Kemp" <[email-masked]>
Date: Tue, 16 Jan 2001 10:36:03 -0500 (EST)

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 <[email-masked]>
> 
> 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.

---

From: Russ Housley <[email-masked]>
Date: Thu, 18 Jan 2001 12:43:12 -0500

I think we may be splitting hairs on the term "issue." I am not
sure that I would consider a CRL that was generated but not distributed
to be "issued."

From RFC 2459:

5.2.4  Delta CRL Indicator

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.

The value of BaseCRLNumber identifies the CRL number of
the base CRL

that was used as the starting point in the generation of
this delta-

CRL.  The delta-CRL contains the changes between the
base CRL and the

current CRL issued along with the delta-CRL.  It is the
decision of a

CA as to whether to provide delta-CRLs.  Again, a
delta-CRL MUST NOT

be issued without a corresponding complete CRL.
The value of

CRLNumber for both the delta-CRL and the corresponding
complete CRL

MUST be identical.

A CRL user constructing a locally held CRL from delta-CRLs
MUST

consider the constructed CRL incomplete and unusable if the
CRLNumber

of the received delta-CRL is more than one greater than the
CRLnumber

of the delta-CRL last processed.

id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27
}

deltaCRLIndicator ::= BaseCRLNumber

BaseCRLNumber ::= CRLNumber

Russ

At 10:36 AM 1/16/2001 -0500, David P. Kemp wrote:

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

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

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."

and

"Note - it is the decision of the CA as to whether or not to
distribute

full CRL must be published anywhere except to /dev/null.  Note
that

(There are technical reasons for requiring only a single
"revocation

state" to exist at any moment in time, and locally constructing a
full

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

Regards,

Dave