Subject: RE: delta CRLs

From: "Tom Gindin" <[email-masked]>
Date: Thu, 3 May 2001 10:33:39 -0400

Why should PKIX drop the "hold" feature?  The only feature which
involves any extra work for the client is "removeFromCRL".  We might want
to make "removeFromCRL" optional to implement and suggest that CA's which
issue delta CRL's SHOULD not use the certificateHold and removeFromCRL
reason codes, but CA's which don't issue deltas aren't imposing any greater
difficulties on the client by using "hold", are they?

          Tom Gindin

Santosh Chokhani <[email-masked]> on 05/03/2001 09:23:56 AM

To:   "Housley, Russ" <[email-masked]>, Denis Pinkas
      <[email-masked]>
cc:   [email-masked]
Subject:  RE: delta CRLs

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