Subject: RE: delta CRLs

From: Santosh Chokhani <[email-masked]>
Date: Thu, 3 May 2001 09:23:56 -0400

Russ: Please note minor word smithing for grammar and for technical
accuracy.  The sentences should read as follows.

"A delta CRL provides an update to a previously issued complete CRL.  A
delta CRL only includes entries for certificates that have changed status
since the complete CRL referenced in the delta CRL extension was issued."

Also a minor technical change to your other sentence:

"An application can construct an updated CRL by retrieving the appropriate
base CRL for that scope, and combining it with a delta CRL which contains a
delta CRL indicator extension with the same CRL number or lower number as
the base CRL."

Please note that the delta CRL can always be applied to a higher base than
the one referenced in the delta CRL extension.

I also agree with Russ that PKIX need not include the "hold" feature.
-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Wednesday, May 02, 2001 9:20 PM
To: Denis Pinkas
Cc: [email-masked]
Subject: Re: delta CRLs

Denis:

For the most part, the text that you provide is an improvement; however, I 
MUST object to a few things.

>5.2.4  Delta CRL Indicator
>
>    The delta CRL indicator is a critical CRL extension that identifies
>    a CRL as being a delta CRL. A delta-CRL is a CRL that only provides
>    information about certificates who statuses have changed since the
>    issuance of a specific, previously issued CRL. The use of delta

I do not like the second sentence any better than the original.  How about:

    A delta CRL provides an updates a previously issued complete CRL.
    A delta CRL only includes entries for certificates that have changed
    status since the complete CRL was issued.

>    CRLs can significantly reduce network load and processing time in
>    some environments.  Delta CRLs are generally much smaller than the
>    CRLs they update, so applications that obtain delta CRLs consume
>    less network bandwidth than applications that obtain the
>    corresponding complete CRLs.
>
>    The delta CRL indicator extension contains a single value of type
>    BaseCRLNumber.  This value identifies the CRL number of the base CRL
>    that was used as the foundation in the generation of this delta CRL.
>    The referenced base CRL is a CRL that was explicitly issued as a CRL
>    that is complete for a given scope (e.g., a set of revocation reasons
>    or a particular distribution point.) The CRL containing the delta CRL
>    indicator extension contains all updates to the certificate
>    revocation status for that same scope.
>
>    When a delta CRL is issued, it MUST cover the same set of reasons
>    and same set of certificates that were covered by the base CRL it
>    references.
>
>    When a conforming CA issues a delta CRL, the delta CRL MUST include
>    a critical delta CRL indicator extension.
>
>    An application can construct a CRL that is the most current for
>    a given scope, for a specific date, by retrieving the appropriate
>    base CRL for that scope, and combining it with a delta-CRL which
>    contains a Delta CRL Indicator equal to the cRLNumber of the base
>    CRL and where the date for which the construction is being made is
>    between thisUpdate and nextUpdate as indicated the delta CRL.

Can we focus on the most common case?  How about:

    An application can construct an updated CRL by retrieving the
    appropriate base CRL for that scope, and combining it with a delta
    CRL which contains a delta CRL indicator extension with the same
    CRL number as the base CRL.

>    Conforming implementations of this specification are not required
>    to implement the above algorithm, but MUST provide functionality
>    equivalent to the external behavior resulting from this procedure.

No.  We do not presently require CRL implementation.  The paragraph would 
seem to change that situation, and require CRL and delta CRL 
implelmentation.  I suggest that the previous paragraph be omitted.

>    CAs must ensure that application of a delta CRL to the referenced

Change "CAs must" to "Conforming CAs that support CRLs and delta CRLs MUST".

>    base revocation information accurately reflects the current status of
>    revocation.  If a CA supports the certificateHold revocation reason
>    the following rules must be applied when generating delta CRLs:

I argued against the inclusion of support for certificate hold in RFC 
2459.  Your text demonstrates the complexity of supporting this feature.  I 
am quite concerned that this topic is being raised so late in the 
process.  We are in WG Last Call ...  [Denis, you will recall that you made 
a similar response to a comment that I made regarding TSP.]

I am still concerned about the significant complexity that certificate hold 
adds.  It makes non-repudiation even more difficult.  Further, I am not 
convinced that there is really a constituency for this feature.

I would be very happy if we changed the profile to say that conforming CAs 
MUST NOT use certificateHold.  I would be happy  if we changed the profile 
to say that conforming CAs SHOULD NOT use certificateHold. I would be quite 
upset if we require clients to support certificateHold in any manner other 
than simply revoked.  (Note that section 5.3.2 provides the conformant 
application the alternative of simply rejecting the certificate.)

What do others think?

>       (a) If a certificate was listed as revoked with revocation reason
>       certificateHold on a CRL (either a delta CRL or a CRL that is
>       complete for a given scope), and the hold is subsequently
>       released, the certificate must be listed with revocation reason
>       removeFromCRL until the next base CRL is issued.
>
>       Note: Should the certificate be subsequently revoked again for
>             one of the revocation reasons covered by the delta CRL,
>             then the certificate must be listed with the revocation
>             reason appropriate for the subsequent revocation.
>
>       (b) If the certificate was not removed from hold, but was
>       permanently revoked, then it must be listed as such on all
>       subsequent delta CRLs until the next base CRL is issued .
>
>    id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
>
>    BaseCRLNumber ::= CRLNumber

Russ

---

From: Stephen Kent <[email-masked]>
Date: Thu, 3 May 2001 09:48:19 -0400

Santosh,

if we want the grammar to be correct, then the second sentence should read:

"A delta CRL includes entries only for certificates that have changed 
status since the complete CRL referenced in the delta CRL extension 
was issued."

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 03 May 2001 16:49:04 +0200

Santosh,

Mails are crossing around, and are not necessarilly received in the same
order. :-)

You indicated "Also a minor technical change to your other sentence" in your
response to Russ:

 "An application can construct an updated CRL by retrieving the appropriate
 base CRL for that scope, and combining it with a delta CRL which contains
 a delta CRL indicator extension with the same CRL number or lower number
 as the base CRL."

What is a "delta CRL which contains a delta CRL indicator extension with
(...) lower number as the base CRL." If you pick this delta CRL then it is
missing some of the information. Unless you speak of the time T and compare
it with thisUpdate and nextUpdate this does not work.

You also said: " Please note that the delta CRL can always be applied to a
higher base than the one referenced in the delta CRL extension."

You now say "higher" in that sentence. This is even more confusing.

Please take note that the intent is to describe what is necessary to support
the "traditional scheme" and I got the feeling that you would like this
sentence to support a different scheme. On April 19, David Cooper provided
some explanations making some confusing between the numering of delta-CRLs
and the numbering of base CRLs. Thay have no relationships besides that the
numbers should always increase.

If I just re-use the text from David, then you get the effect he wanted
without the need to take advantage of any new sequential numbering. Here is
the corrected text:

" Suppose that delta-CRLs are issued once an hour. For example, suppose that
a base CRL, CRL number 5, was issued at midnight and that every hour for the
next 24 hours, delta-CRLs were issued with a BaseCRLNumber of 5. If a
relying party performs its first validation at 3:10am, it would the base CRL
issued at midnight and the delta-CRL issued at 3:00am (e.g. CRL number 28).
It would combine these to construct the freshest CRL.

A few hours later, at 6:30am, the relying party performs another validation.
The relying party has, in its local cache, the CRL which it constructed at
3:10am. It wants to update the information in its local case to based on the
newly available revocation information. So, it obtains the latest delta-CRL.
This delta-CRL has a CRL number of 42 and a BaseCRLnumber of 5. Since
it has a BaseCRLNumber of 5, the delta-CRL provides status information for
all certificates whose status has changed since CRL number 5 was issued
(midnight). So, clearly the delta-CRL provides status information for all
certificates whose status has changed since 3:00am when CRL number 28 was
issued. Thus, the relying party can combine the delta-CRL with its locally
cached version of the CRL which it constructed at 3:10am to obtain the
freshest CRL."

So the addition you were proposing is not adequate. If we were going to
support variations beyond the traditional scheme, this should be in a
separate sentence.

Regards,

Denis