Subject: Re: delta-CRLs

From: Denis Pinkas <[email-masked]>
Date: Wed, 02 May 2001 16:43:02 +0200

David,

On monday 23 April, I sent you the following long e-mail, and since I got no
reply to it I would guess that you agree with it. So it is now the right
time to fix the text.  What follows is a full replacement proposal for
section 5.2.4. It simplifies the current text making it easier to read and,
when delta CRLs are supported, only mandate the support of what you call
"the traditional method".

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

   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.

   CAs must ensure that application of a delta CRL to the referenced
   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:

      (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

Regards,

Denis

==========================================================================

This is a LONG e-mail and a last e-mail to you, before leaving for a trip
that will keep me away from my e-mails during a week. So, don't think I am
giving up if you do not receive a reply soon.

> Denis,
> 
> My comments are in line.
> 
> At 06:50 PM 4/20/01 +0200, Denis Pinkas wrote:
> >[Denis] This is the case I had in mind. However I would disagree to say that
> >the locally contructed CRL is equal to the full CRL number 8, because there
> >is no need to issue such CRL (see the first comment). It is simply the
> >"freshest CRL constructed from the base CRL number 5 for 3:10 am". This
> >locally contructed CRL bears no number, or if you assign one, this is a
> >local matter and is not part of the standard. This also avoids the later
> >confusing between CRL numbers.
 
[David] This is simply not true. 

[Denis] The sentence above is technically correct: "It is simply the
freshest CRL constructed from the base CRL number 5 for 3:10 am".
 
[David] A delta-CRL can (will) contain the cRLNumber extension just as a
full CRL will. 

[Denis] The cRLNumber extension is simply an identifier that allows you to
uniquely identify it and to know whether it is earlier or later another CRL
issued by the same CRL issuer.

[David] If a full CRL and a delta-CRL are issued at the same time, the
combination of the delta-CRL and an appropriate base CRL must be equivalent
to the full CRL, and both the delta-CRL and the full CRL must have the same
cRLNumber. 

[Denis] This is where we do not agree. The delta-CRL and the full CRL MUST
NOT have the same cRLNumber because this would violate the definition of
what is a CRLnumber. RFC 2459 says: 

5.2.3  CRL Number

   The CRL number is a non-critical CRL extension which conveys a
   monotonically increasing sequence number for each CRL issued by a CA.
   This extension allows users to easily determine when a particular CRL
   supersedes another CRL.  CAs conforming to this profile MUST include
   this extension in all CRLs.

Maybe you are making some confusion with the deltaCRLindicator. 

The construction you mention is not acceptable and is no even part of the
ISO X509 document.

[David] If a delta-CRL is issued, and no corresponding full CRL issued, then
the combination of the delta-CRL and an appropriate base CRL should be
equivalent to the full CRL that would have been issued at that time, if a
full CRL had been issued. 

[Denis] Here is the problem ! Let us take an example: A base CRL
is issued at midnight. thisUpdate is set to midnight while nextUpdate is
midnight for the next day. This means that there is no guarantee at all that
any other base/full CRL will necessarily be seen within the next 24 hours.
Certainly a base can be issued before, but once again there is no guarantee
that it will ever be seen. If someone is now using the CRL as a proof to be
presented later on that the certificate was not revoked, a relying party 
is perfectly right to use the base from midnight (if allowed by the
validation policy) or the base plus a delta (if mandated by the validation
policy).    

Now if you issue a full CRL (I did not say a base CRL) every hour at the
same time you issue a delta, the problem becomes worse because at 11:30 p.m.
you have now 23 full CRLs, and you cannot know which one is the right one to
use (if someone purposely is blocking the transmission of the latest full
CRLs), unless precisely you introduce he statement that is the cause of all
this trouble:

   When a conforming CA issues a delta CRL, the CA MUST also issue a CRL
   that is complete for the given scope.  

Now understand better the problem: this is a stone fundation of the whole
edifice. If we take it away, the whole edifice collapses.

Anyway, the intention has never been that relying parties will necessarilly
get the same level of information when using only base CRLs and when using
base CRLs plus deltas.

The question which arises now is what are the implications if a full CRL is
issued at the same time a delta is issued and when we apply the modified
sentence:

   When a conforming CA issues a delta CRL, the CA MAY also issue a full CRL
   that is complete for the given scope.  

In this case the relying pary is using the delta (*in the way I have
described it*), i.e. testing thisUpdate and nextUpdate from the delta CRL,
it will get a GUARANTEE to obtain either the freshest revocation
information or it will know that the freshest revocation information is not
available.

In the case the relying pary is using not using the delta, he will have no
GUARANTEE that the information he got is the freshest.

[David] The delta-CRL should have the same cRLNumber as would have been
assigned to a full CRL issued at the same time.

[Denis] Once again, I disagree, since this would violate the definition of
CRL Number given in section 5.2.3. 
 
[David] A delta-CRL is nearly the same as a full CRL. It has a thisUpdate,
nextUpdate, cRLNumber, etc. just as a full CRL. It just has an incomplete
list of revoked certificates.

[Denis] Yes, but you have to explain detail how a relying party will use
thisUpdate, nextUpdate for a base CRL and thisUpdate, nextUpdate for a delta
to make sure that in both cases he got the freshest information.

Remember that RFC 2459 says:

   The behavior of clients processing CRLs which
   omit nextUpdate is not specified by this profile.

So, in order to be PKIX compliant, you cannot escape a sentence which tells
what use is made of that field.

> > > A few hours later, at 6:30am, the relying party performs another validation. The relying party has, in its local
cache, the contents of CRL number 8 (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 11 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 8 was issued. Thus, the relying
party can combine the delta-CRL with its locally cached version of full CRL
number 8 to obtain the contents of CRL number
11. This is a case where the CRL number of the complete CRL used is greater
than the BaseCRLNumber specified in the
delta-CRL.

> >[Denis] This is a local matter and I would not mandate this in the document
> >since there is another and simpler way to do it: you keep in the cache the
> >base CRL (instead of the previously recontructed full CRL). This has the
> >same end result, except that the method your recommend is not optimum: it
> >will include many duplicates and deleting the duplicates is more painfull
> >than making a simple addition.
 
[David]  I'm not sure what you are saying is a local matter. The contents of
the delta-CRL is not a local matter and must be mandated in the certificate
and CRL profile. If you prefer to always apply the delta-CRLs to the
referenced base CRL instead of to a locally generated, more recent CRL, that
is your choice. The document states that the delta-CRL may be combined with
the referenced base CRL or a more recently issued full CRL.

[Denis] 

As said later, your paper provides the right answer (on page 1): " 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 text says " *a* specific, previously issued CRL", it does NOT say
"or any, more recently, issued CRL". Now I understand that you may get the
same final result (in a less efficient way), if such a CRL has been issued
and if it could have been seen by the relying party. I would propose that we
describe in the text, the basic rule. I would have no problem to mention in
a note that the same result COULD also be obtained, IF a full CRL were
issued
after the base.

> >The basic algorithm is to take the base CRL and to add the delta. This is
> >the standard. As soon as you get the same end result this is fine. This is
> >the approach we have taken for path validation. Other ways do not need to be
> >mentionned.
> >
> > > There are other reasons why the two numbers may not match, but I will not go into them. If you are interested, you
can read my paper.
> >
> >[Denis] I read it (and skipped the mathematical formulas)
> >
> >This paper is proposing a method for over-issuing the CRLs. It omits to take
> >into consideration that in PKIX-1 we mandate the CRL number extension
> >(section 5.2.3) so we need to advertise the nextUpdate. If you issue a CRL
> >before the next update you have no more way to know which base CRL is the
> >freshest CRL. I believe this is a major security weakness and for that
> >reason this mechanism should be deprecated.

[David]  The paper does discuss over-issuing of CRLs, but there is plenty of
information about using delta-CRLs efficiently without over-issuing. Bear in
mind, however, that the nextUpdate field only specifies the time by which a
new CRL will be issued. Many people intend to issue a new CRL whenever a
revocation occurs (or a revocation for key compromise) without waiting until
the regularly scheduled time.

[Denis] As said earlier, without any guarantee that the fullCRL issued
before nextUpdate will be seen until the validation time has passed
nextUpdate. 

> >BTW, the same security problem would occur as soon as a base would be used
> >for every delta. Hence another good reason to delete the sentence which
> >originally triggered all this discussion.
> 
> I don't understand this at all.
> 
> >BTW, I noticed that you have precisely deleted from my previous e-mail all
> >the text dealing with this nextUpdate. :-(
> >
> >So I am still insisting on the major text change to make to that section:
> >
> >    An application can construct a CRL that is the most current for
> >    a given scope, at the current time, by retrieving the current
> >    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 current date from that delta-CRL is between
> >    thisUpdate and nextUpdate;
> >
> >It is important to notice that the algorithm does NOT use the individual CRL
> >numbers assigned to the delta-CRLs, but uses instead thisUpdate and
> >nextUpdate. This is *very* important.
 
[David]  I thought I did respond to this. First, one should expect that
delta-CRLs will always be at least as recent as base CRLs. So the first step
should be to obtain the current delta-CRL. Next, one obtains a base CRL that
can be used in combination with that delta-CRL. You may choose to only use
the full CRL whose cRLNumber is equal to the BaseCRLNumber specified in the
delta-CRL, however, any full CRL with a cRLNumber greater than or equal to
the BaseCRLNumber is acceptable. 

[Denis] Your algorithm is looking at the CRL Numbers only. My algorithm is
looking at thisUpdate and nextUpdate only. This is a major difference. In
particular you do not say how "to obtain the current delta-CRL".

[David] Since the cRLNumber of the base can be greater than the specified
BaseCRLNumber, the document should say so. 

[Denis] This can be mentionned in a note (see earlier).  

[David] There is no need to state that the current time must be after the
thisUpdate time in the delta-CRL as this will always be true by
construction. 

[Denis] There is definitively a need to state this because the end result of
the two algorithms will not be identical as soon as someone will block some
of the information coming from the repository where the full/base CRLs are
stored or where the delta CRLs are stored.

[David]  Finally, since a CRL issuer may issue "emergency" delta-CRLs, there
is no guarantee that any delta-CRL whose nextUpdate time is later than the
current time is the most current delta-CRL.

[Denis] If you issue such "emergency" delta-CRLs then once again there is no
guarantee that they will ever be seen. The "most recent delta-CRL" is any
delta CRL which satisfies the following condition :

" A delta-CRL which contains a Delta CRL Indicator equal to the cRLNumber of
the base CRL and where the validation date (which may be the current time)
is between thisUpdate and nextUpdate from that delta-CRL;"
 
> > > >Finally we should explain what happens at the boundaries, i.e. when a CA
> > > >decides to generate a (new) base CRL. Here is a text proposal:
> > > >
> > > >   When issuing a base CRL that supports a delta-CRL mechanism then the
> > > >   CRL Issuer MUST at the same time issue a delta CRL that points to that
> > > >   base CRL. This first delta CRL will usually be empty (or will include
> > > >   last-minute additions to the base CRL).

> > > This is not acceptable. The rule is that when a base CRL is issued a delta-CRL must be issued that has the same
cRLNumber. The base CRL referenced by the delta must either be the
previously issued base CRL or a base CRL issued before
that one. Since the new base and the delta must have the same cRLNumber,
there can be no differences as a result of
"last-minute additions to the base CRL".

> >[Denis] This does not work. Let me explain it differently. Suppose that
> >during the week you do not generate delta-CRLs but for the week-end you
> >decide to do it (e.g. more risk, more transactions done by citizens). So you
> >issue a CRL with the freshest CRLindicator. You say that the delta points to
> >the previous base CRL. The one from yesterday or the one from last week ?
> >In either case this simply does not work.
 
[David]  Why? A delta-CRL must include a BaseCRLNumber that corresponds to a
CRL that was issued at some time in the past.

[Denis]  A delta-CRL must include a BaseCRLNumber that corresponds to a CRL
that was issued at some time in the past *or to the current time*. The above
example demonstrates that the rule does not work the first time you use it
since there is no such past base CRL or an ambiguity about which one is the
right one. Since it is not possible to answer the question I raised (i.e.
does the first delta points to one from yesterday or the one from last 
week ?) this is one way to demonstrate that there is a problem.

> >The rule you mention, i.e. "The rule is that when a base CRL is issued a
> >delta-CRL must be issued that has the same cRLNumber" is also wrong. The
> >notion of a base CRL that would have the same number as a delta does not
> >exist.

> > > >Suppose we issue a base CRL every midnight. The question is whether we
> > > >should issue a delta and, if yes, does this delta refer to the previous
> > > >base or to the new one ?

> > > The delta must refer either to the previous base or a base issued before the previous base.

> >[Denis] Certainly not. Your paper however provides the right answer
> >(on page 1): " 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".
 
[David] Where is the difference? A CRL that is referenced in the
BaseCRLNumber of a delta-CRL is by definition a base CRL.

[Denis] The difference lies in the fact that the sentence is using the
wording "*a* specific, previously issued CRL". If it is *a* (i.e. one)
specific CRL, it cannot be more than one.
 
> > > >Suppose it refers to the previous one. According to the current sentence:
> > > >"The constructed CRL has the CRL number specified in the CRL number
> > > >extension found in the delta CRL used in its construction.", it is
> > > >impossible. If that was the case the delta CRL would have a CRL number equal
> > > >to the base CRL and it is not allowed for two CRLs to have the same CRL
> > > >number.
> >
> > > I think you are confusing two different extensions. The deltaCRLIndicator extension contains a BaseCRLNumber which is
used to determine against which base CRLs the delta-CRL can be applied. The
cRLNumber extension specifies the CRL number of
the full CRL that will be generated by applying the delta-CRL to a base CRL.
The sentence above states that the CRL number
of the constructed CRL is taken from the cRLNumber extension, not the
BaseCRLNumber of the deltaCRLIndicator extension.
> >
> >[Denis] I do not think I make a confusion. The confusion comes from the
> >numbering you introduce (see my earlier comment).
> >
> >Let me conclude:
> >
> >1) I do not have the time to spend hours of discussions on that topic.
> >However the current text needs to be corrected and I have provided text
> >for this. Please take again a look at it in the light of the following.
> >
> >2) In your paper you advertise the "traditional delta-CRLs". Let us stay in
> >the tradition and let us mandate the implementation of the "tradition" if
> >someone wans to support the delta-CRL mechanism.
> >
> >Any other method would first need to be proven to be secure (over-issuing
> >CRLs and sliding window delta-CRLs have security problems) and should
> >*anyway* fall in the MAY category, so that noone needs to implement to claim
> >conformance with the delta CRL mechanism. Standard track documents need to
> >make choices among multiple methods, otherwise two different implementations
> >will never interoperate.
 
[David] you say that you want to stick with "traditional" delta-CRLs,
however you are proposing changes to the text that would not result in
"traditional" delta-CRLs but would result in broken implementations. 

[Denis] You have provided no evidence of what you say just above. Tell me
precisely what is wrong in the text I propose that would not allow the
support of the "traditional" delta-CRLs. If something is wrong, we can fix
it.

[David] We do not prevent people from implementing "traditional" delta-CRLs,
but we should not force them to either. 

[Denis] We disagree here. Standards are there to support at least one
(simple) method that all implementations have to support( if they support
delta). In addition, implementations may support additional methods and it
will be up to the final customer to decide which one to use. We MAY describe
these additional methods, but MUST clearly indicate the difference.
 
[David] There are no security problems with sliding window delta-CRLs and
they do not add any complexity for those who choose not to
implement them.

[Denis] There ARE security problems with sliding window delta-CRLs. I have
descibed at length what the problems are. However, this does not mean that
this technique cannot be supported as an OPTIO and IF we indicate in the
text what are their security problems. The current text places the two
techniques at the same level. The traditional way offers a guarantee while
the other does not. There is indedd added complexity for building the
software from the relying party. 

[David]  I want to be sure that the delta-CRL text is correct just as you
do, 

[Denis]  At least one point on which we both agree. :-)

[David] ... but I still feel that many of your comments are based on a
misunderstanding and are not based on actual problems in the text.

[Denis] I do hope that after this response you will think differently.

Regards,

Denis

> Dave

---

From: Tim Polk <[email-masked]>
Date: Wed, 02 May 2001 11:40:34 -0400

Denis,

Sorry about the silence from NIST.  I was supposed to write the 
reply.  Since you were out last week, I delayed writing the response to 
deal with other, more immediate, crises...

Anyway, the list has agreed that we should remove the requirement for 
issuing full CRLs with every delta.  Since we don't even require issuing 
CRLs at all, it would be inappropriate for us to be heavily prescriptive 
regarding *how* deltas must be implemented.  Basically, I believe the 
modifications you propose are out of scope.

I also should note that we (David Cooper & I) disagree with the 
requirements you have stated.  They seem to depart from the traditional 
deltas in certain details, but prevent use of sliding window deltas.  We 
can continue to discuss effective delta CRL strategies off-line, but I 
believe that no additional changes are required or appropriate in 
son-of-2459. (I do accept that we should remove the requirement for full 
CRLs with each delta.  I believe that reflects the consensus of the list as 
well.)

Thanks,

Tim Polk

At 04:43 PM 5/2/01 +0200, Denis Pinkas wrote:
> > > > A few hours later, at 6:30am, the relying party performs another 
> validation. The relying party has, in its local
> > > > There are other reasons why the two numbers may not match, but I 
> will not go into them. If you are interested, you
>can read my paper.
> > >
> > > > This is not acceptable. The rule is that when a base CRL is issued 
> a delta-CRL must be issued that has the same
> > > > I think you are confusing two different extensions. The 
> deltaCRLIndicator extension contains a BaseCRLNumber which is

---

From: Jeff Jacoby <[email-masked]>
Date: Wed, 02 May 2001 10:04:26 -0700

Greetings,

I would like to suggest one minor addition (though perhaps painfully 
obvious to most) ...

>    issuance of a specific, previously issued CRL. The use of delta

It's not obvious to me if this "previously issued CRL" is supposed to be
the base CRL or if it's a prior delta CRL.  Would it be worthwhile to 
specifically say:

    "issuance of a specific, previously issued base CRL."

Or if it can be either base CRL or delta CRL then perhaps the text
should
specifically say that.  

[I have been unable to follow this thread is closely as I would like and
so I apologize if this issue was clearly covered elsewhere/elsewhen.]

>    corresponding complete CRLs.

[great big snip]

Jeff

-- 
Jeff Jacoby, Sr. Programmer
RSA Security Inc., SMDC

2755 Campus Dr., Ste. 300	[email-masked]
San Mateo, CA  94493		(650) 295-7569

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 02 May 2001 19:18:15 +0200

Jeff,

>     "issuance of a specific, previously issued base CRL."

This is the correct answer. :-)

Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 02 May 2001 21:20:13 -0400

Denis:

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

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

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

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

>    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?

>    BaseCRLNumber ::= CRLNumber

Russ

---

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

Russ,

Thank you for your response.
 
> MUST object to a few things.

:-)
 
>     status since the complete CRL was issued.

This sentence was nearly a copy and paste from a sentence written by David
Cooper in his paper. I would have no problem to have two short sentences
instead of a long one. I would however like to make an observation. I have
been using the term "base CRL" when it is a CRL that is advertised to
support delta CRLs. I have ben using the term "complete" CRL for a CRL that
does NOT support delta CRLs. According to this convention, I would change
"complete" into "base". This would lead to:

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

 
>     CRL number as the base CRL.

This does not work, since the sentence does not speak anymore about the time
and thus there is no guaranty that what you get is the "freshest". Remember
that the extension for advertising delta is (mis-)named freshestCRL ! 
I would have no problem to have two short sentences instead of a long one. 
How about:

   An application can construct an updated CRL, for a specific time T, 
   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. Time T MUST fall between 
   thisUpdate and nextUpdate for both the base CRL and the delta CRL.

> implelmentation.  I suggest that the previous paragraph be omitted.

I understand what you mean, but this was not the intent. How about:

   Conforming implementations supporting delta-CRLs are not required
   to implement the above algorithm, but MUST provide functionality
   equivalent to the external behavior resulting from this procedure.

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

Fine.

> a similar response to a comment that I made regarding TSP.]

The text was there, it has not been added now. I have only corrected the
text. So I am not advocating the addition of on hold now. I could reverse
the argument saying that I am surprised that in WG last call, *you* now
would like certificate hold to be removed everywhere in the document.

Coming back to the technical arguments only, when "on hold" was introduced
(many years ago) I originally believed that there could be some problems
when being used in the context of a non repudiation service. I have not
been able to find a single case where there would be a problem.
 
> application the alternative of simply rejecting the certificate.)

This is clearly a much wider topic, that is not solely directed to
delta-CRLs. So I would request that people interresting to debate along this
topic change the title of the thread to someting like: "certificate hold".

As far as I am concerned, until I will see an argument where the use of hold
creates more problems than its non-use, I see no reason why we should make a
change to the document.

Regards,

Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 03 May 2001 13:17:08 -0400

Fine.

> > >    corresponding complete CRLs.

Did you want to rephrase this to get rid of complete here too?

>    thisUpdate and nextUpdate for both the base CRL and the delta CRL.

Okay, however, we should say: Applications that support delta CRLs MUST 
ensure that time T falls between thisUpdate and nextUpdate for both the 
base CRL and the delta CRL.

>    equivalent to the external behavior resulting from this procedure.

Reading the previous paragraph, I do not think that we need to have this 
paragraph at all.  The previous paragraph does not actually include an 
algorithm.

>would like certificate hold to be removed everywhere in the document.

Fair reply.  And, unless there is a ground swell of support, I will drop it.

>been able to find a single case where there would be a problem.

When trying to determine if a certificate was valid at a particular time T 
(in the significant past), an application must recreate the history of 
on-hold/off-hold events near time T.

>creates more problems than its non-use, I see no reason why we should make a

Fair request.

Russ

---

From: "Carlin Covey" <[email-masked]>
Date: Thu, 3 May 2001 10:44:10 -0700

Russ and Denis,

I was somewhat confused about your positions on the "hold" feature.
Having read the email below, I am now REALLY confused.

Based on context, I interpreted Denis' comment:
"So I am not advocating the addition of on hold now."
to mean
"I have not recently switched my position on 'hold'."

Denis, is that correct?

Russ, it appears from your comment:
"Fair reply.  And, unless there is a ground swell of
support, I will drop it."
that you have interpreted Denis as meaning
"I have withdrawn my support for 'hold'."

Russ, is that correct?

And Russ, I am further confused by "... I will drop it."

Did you mean that you will add text to prohibit compliant
CA's from issuing delta CRL's that include "hold" and
"removeFromCRL" reason codes or text that will prohibit
this for full CRL's as well as delta-CRLs, or did you
mean something else entirely?

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Thursday, May 03, 2001 10:17 AM
To: Denis Pinkas
Cc: [email-masked]
Subject: Re: delta CRLs

Fine.

Fair request.

Russ

---

From: Tim Polk <[email-masked]>
Date: Thu, 03 May 2001 15:29:56 -0400

Denis,

You seem to be advocating one *extremely* limited scenario for the use of
delta CRLs.  Under your text, deltas may only be used with a
specifically issued base CRLs.  That is, the application of delta
CRLs to constructed CRLs seems to be forbidden.  We believe this
scenario is inefficient and reduces or cancels completely the benefits of
delta CRLs.

Simple processing of the CRL number extension can support more efficient
delta CRL processing.  These techniques permit an application to
store revocation information in more efficient formats (e.g., a local
database) and apply updates to that information.  I do not
understand the problems you have with using the CRL number extension in
deltas; the concepts in son-of-2459 are aligned with the requirements
stated in X.509.  You have also deleted important points in the
processing of certificate hold, as those points do not apply in your very
limited scenario.

The current text was very carefully crafted to be correct, complete, and
aligned with the X.509 standard.  I believe that the current text is
correct, and should be maintained.

I will compare the two sets of text, and describe the rationale for the
original text.

First paragraphs are nearly identical.  You have replaced the second
sentence and deleted the last sentence.  You replaced:

Delta CRLs contain updates to revocation information previously
distributed, rather than all the information that would appear in a
complete CRL.

with:

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.

That change is fine.  However, you delete the final
sentence:

Applications which store revocation information in a format other
than the CRL structure can add new revocation information to the local
database without reprocessing information.

I believe that is appropriate for your text, since the algorithm
seems to *require* reprocessing a base whenever a delta is
processed.  Unfortunately, adding new revocation information without
reprocessing information is an important benefit of delta CRLs.  I
suspect that is why we disagree so vehemently.

In the second paragraph, you again deleted the last sentence:

The combination of a CRL containing the delta CRL indicator extension
plus the CRL referenced in the BaseCRLNumber component of this extension
is equivalent to a full CRL, for the applicable scope, at the time of
publication of the  delta CRL.

Why was this text deleted?  By deleting this text, you impose
unnecessary limitations on the use of deltas.  This seems to force
the delta CRL user to obtain new base CRLs rather than use constructed
CRLs.

The third paragraph needed to be revised anyway, since it incorporates
the old constraints that full CRLs and deltas be issued together.
However, you deleted all the information regarding the use of the CRL
number extension in delta CRLs.  This is important
information:

Current text:

When a conforming CA issues a delta CRL, the CA MUST also
issue a CRL

that is complete for the given scope.  Both the delta
CRL and the

complete CRL MUST include the CRL number extension (see sec.
5.2.3).

The CRL number extension in the delta CRL and the complete
CRL MUST

contain the same value.  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.

You deleted all but the last sentence.  The CRL number extension is
required in delta CRLs so that future delta CRLs can be applied to the
new constructed base CRL.

You have inserted a new paragraph four:

I am surprised we missed this one.  We should keep this
text.

Current text for paragraphs four and five are:

An application can construct a CRL that is complete for a
given

scope, at the current time, in either of the following
ways:

(a) by retrieving the current delta CRL
for that scope, and

combining it with an issued CRL that is
complete for that scope

and that has a cRLNumber greater than or
equal to the cRLNumber of

the base CRL referenced in the delta CRL;
or

(b) by retrieving the current delta CRL
for that scope and

combining it with a locally constructed
CRL whose cRLNumber is

greater than or equal to the cRLNumber of
the base CRL referenced

in the current delta CRL.

The constructed CRL has the CRL number specified in the CRL
number

extension found in the delta CRL used in its
construction.

You've replaced this with:

First, the CRL that is constructed (in either text) may be complete
for a given scope and time, but there is no way to demonstrate that the
constructed CRL is "the most current".   We can never
be sure that we haven't missed an emergency CRL (or delta CRL.)  We
can only be sure that we haven't reached the next scheduled CRL
publication date.

In addition, you have deleted the semantics of the CRL number extension
in delta CRLs.  Instead, you substitute text on nextUpdate and
thisUpdate, which are independent extensions and have been covered
elsewhere.

You have inserted a new paragraph:

First, I don't really see an algorithm.  Second, as Russ has pointed
out, we don't require processing of deltas at all.

The current text closes with:

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

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:

(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), whose
cRLNumber is n, and the hold is

subsequently released, the certificate
must be included in all

delta CRLs issued after the hold is
released where the cRLNumber

of the referenced base CRL is less than or
equal to n. The

certificate must be listed with revocation
reason removeFromCRL

unless the certificate is subsequently
revoked again for one of

the revocation reasons covered by the
delta CRL, in which case 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 on all subsequent

delta CRLs where the cRLNumber of the
referenced base CRL is less

than the cRLNumber of the CRL (either a
delta CRL or a CRL that is

complete for the given scope) on which the
permanent revocation

notice first appeared.

You replace this with:

This text presents the biggest problems of all.  The text
describes *what* needs to be listed on *which* delta CRLs.  By
limiting this text to one very narrow scenario, you increase the
likeliehood that delta CRL issuers that wish to do something efficient
will get it wrong.  That will result in bad information fro the
relying party.

The current text was very carefully crafted to ensure that it was
consistent with X.509 and supported the general case.  I do not see
the need to hamstring delta CRL implementers by limiting support to one
narrowly defined scenario.

Tim Polk

---

From: "Carlin Covey" <[email-masked]>
Date: Thu, 3 May 2001 14:38:12 -0700

Tim,

Just to set the record straight, Russ Housley proposed the "new paragraph
four"
in an email on 4/26.  See below.

Regards,

Carlin

-  Carlin Covey
   Cylink Corporation

----------------------------------------------------------------------------
-------------------------------------
    Carlin:

    I would prefer to leave the first sentence alone. I think that it is

    explanation of delta CRLs. However, I like your point, and suggest the

    addition of the following paragraph:

    When a conforming CA issues a delta CRL, the delta CRL MUST include a

    critical delta CRL indicator extension.

    Russ

  -----Original Message-----
  From: Tim Polk [mailto:[email-masked]]
  Sent: Thursday, May 03, 2001 12:30 PM
  To: Denis Pinkas; David A. Cooper; pkix
  Subject: Re: delta-CRLs

 <snip>

  I am surprised we missed this one.  We should keep this text.

 <snip>

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 04 May 2001 14:01:17 +0200

Tim,

I think we can solve the main problem you mention rather easily. Several
people, including Russ, had difficulties to understand the wording -and the
reason- of the following paragraph:

The reason of that paragraph was to say that if you have a different
technique to reconstruct the CRL, but if you get the same result, this is
equally acceptable. That paragraph was especially there to cover the case
you mention. You get the same result if you use a previously locally
reconstructed CRL. Now that you know the intent, I would propose to change
that paragraph. Taking into account the last proposal from Russ, this would
lead to the two following paragraphs:

   An application can construct an updated CRL, for a specific time T, 
   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. Applications that support 
   delta CRLs MUST ensure that time T falls between thisUpdate and 
   nextUpdate for both the base CRL and the delta CRL.

   Note: An application could also reconstruct an updated CRL, for 
   a specific time T, by using a previously locally reconstructed CRL 
   based on a given base CRL, and combining it with a delta CRL which 
   contains a delta CRL indicator extension with the same CRL number as 
   the base CRL.
 
I think this closes the issue.

People not interrested in the details do not need to look any further down
into this e-mail. However, I will nevertheless comment briefly for those
interrested in the details the remaining of that e-mail.

> delta CRLs.  Under your text, deltas may only be used with a specifically
> issued base CRLs.  That is, the application of delta CRLs to constructed
> CRLs seems to be forbidden.  We believe this scenario is inefficient and
> reduces or cancels completely the benefits of delta CRLs.

See the response above.

> delta CRL processing.  These techniques permit an application to store
> revocation information in more efficient formats (e.g., a local database)
> and apply updates to that information.  I do not understand the problems
> you have with using the CRL number extension in deltas; the concepts in
> son-of-2459 are aligned with the requirements stated in X.509.  You have
> also deleted important points in the processing of certificate hold, as
> those points do not apply in your very limited scenario.
> 

I do *not* believe that the current text is correct, and thus it should
*not* be maintained.

>      certificates who statuses have changed since the issuance of a
>      specific, previously issued CRL.
> 
> That change is fine.  However, you delete the final sentence:
> 
>      than the CRL structure can add new revocation information to the
>      local database without reprocessing information.
> 
> I believe that is appropriate for your text, since the algorithm seems to
> *require* reprocessing a base whenever a delta is processed.
> Unfortunately, adding new revocation information without reprocessing
> information is an important benefit of delta CRLs.  I suspect that is why
> we disagree so vehemently.

We do not. See the explanations on top of this e-mail.

>      plus the CRL referenced in the BaseCRLNumber component of this
>      extension is equivalent to a full CRL, for the applicable scope, at
>      the time of publication of the  delta CRL.
> 
> Why was this text deleted?  By deleting this text, you impose unnecessary
> limitations on the use of deltas.  This seems to force the delta CRL user
> to obtain new base CRLs rather than use constructed CRLs.

Same. See the explanations on top of this e-mail.

> The third paragraph needed to be revised anyway, since it incorporates the
> old constraints that full CRLs and deltas be issued together.  However,
> you deleted all the information regarding the use of the CRL number
> extension in delta CRLs.  This is important information:
> 
> Current text:
> 
>    that is complete for the given scope.  Both the delta CRL and the
>    complete CRL MUST include the CRL number extension (see sec. 5.2.3).
>    The CRL number extension in the delta CRL and the complete CRL MUST
>    contain the same value.  When a delta CRL is issued, it MUST cover
>    the same set of reasons and same set of certificates that were
> required in delta CRLs so that future delta CRLs can be applied to the new
> constructed base CRL.

Certainly there is a CRL number extension in a delta CRL, but this is no
need to use it in the "algorithm" to reconstruct the "full" CRL. So there is
no need to add any *new* or additioal semantics to it. Your proposal would
add such a new semantics. In other words, this new semantics is NOT
required.

:-)

>    An application can construct a CRL that is complete for a given
>    scope, at the current time, in either of the following ways:
> 
>       (a) by retrieving the current delta CRL for that scope, and
>       combining it with an issued CRL that is complete for that scope
>       and that has a cRLNumber greater than or equal to the cRLNumber of
>       the base CRL referenced in the delta CRL; or
> 
>       (b) by retrieving the current delta CRL for that scope and
>       combining it with a locally constructed CRL whose cRLNumber is
>       greater than or equal to the cRLNumber of the base CRL referenced
>    The constructed CRL has the CRL number specified in the CRL number
>    extension found in the delta CRL used in its construction.
> 
> First, the CRL that is constructed (in either text) may be complete for a
> given scope and time, but there is no way to demonstrate that the
> constructed CRL is "the most current".   We can never be sure that we
> haven't missed an emergency CRL (or delta CRL.)  We can only be sure that
> we haven't reached the next scheduled CRL publication date.

This is exactly where you missed the point.

Remember the second sentence of the "algorithm": "Applications that support
delta CRLs MUST ensure that time T falls between thisUpdate and nextUpdate
for both the base CRL and the delta CRL."

With this sentence you can be sure that either you have the latest or you
missed it. I can give you further details. If the CA issues a base CRL then,
it will issue delta CRLs. Every delta CRL will contain the most recent
information. There is no concept of emergency delta CRL. So for relying
parties taking advantage of delta CRLs they cannot miss something or they
will discover that they indeed missed something.

> In addition, you have deleted the semantics of the CRL number extension in
> delta CRLs.  

Certainly. I explained that the right "algorithm" makes use of nextUpdate
and thisUpdate and thus does need to care about the numbering of delta CRLs.
So no extra semantics is needed.

> Instead, you substitute text on nextUpdate and thisUpdate,
> which are independent extensions and have been covered elsewhere.

They were not covered at all.

> First, I don't really see an algorithm.  Second, as Russ has pointed out,
> we don't require processing of deltas at all.

See the explanations on top of this e-mail.

>       complete for a given scope), whose cRLNumber is n, and the hold is
>       subsequently released, the certificate must be included in all
>       delta CRLs issued after the hold is released where the cRLNumber
>       of the referenced base CRL is less than or equal to n. The
>       certificate must be listed with revocation reason removeFromCRL
>       unless the certificate is subsequently revoked again for one of
>       the revocation reasons covered by the delta CRL, in which case the
>       certificate must be listed with the revocation reason appropriate
>       permanently revoked, then it must be listed on all subsequent
>       delta CRLs where the cRLNumber of the referenced base CRL is less
>       than the cRLNumber of the CRL (either a delta CRL or a CRL that is
>       complete for the given scope) on which the permanent revocation
>       notice first appeared.
> 
> You replace this with:
> 
> This text presents the biggest problems of all.  The text describes *what*
> needs to be listed on *which* delta CRLs.  By limiting this text to one
> very narrow scenario, you increase the likeliehood that delta CRL issuers
> that wish to do something efficient will get it wrong.  That will result
> in bad information from the relying party.

This text has be simply adapted to remove the semantics that existed on the
CRL number from delta-CRLs. It describes what a CA does, not what a relying
party does. I do not believe that there is the limitation as you mention. If
you really think that the text needs to be changed, please make a proposal
on it, but without adding any new seamntics to the CRL number. :-)

> consistent with X.509 and supported the general case.  I do not see the
> need to hamstring delta CRL implementers by limiting support to one

The revised text has been very carefully crafted to ensure that no new
semantics was introduced and that a simple scheme can be implemented so that
interoperability can be easily obtained.

Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 04 May 2001 13:30:14 -0400

>mean something else entirely?

I have NEVER liked the on-hold feature.  I still do not like the on-hold 
feature.

I will not delay the Last Call process on son-of-rfc 2459 to debate the 
issue unless I see that there are others that support my view.

Clear?

Russ

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 04 May 2001 14:16:22 -0400

Denis:

I can live with these.

>Taking into account the last proposal from Russ, this would

Russ

---

From: "Carlin Covey" <[email-masked]>
Date: Fri, 4 May 2001 11:34:31 -0700

Russ, your feelings on the hold feature were, and are, quite clear.
I am not advocating inclusion of the hold feature in son-of-rec-2459,
nor am I proposing that we should delay progress by debating the issue.
But given that son-of-rfc-2459 contains language related to the hold
feature, I was wondering what your words "... I will drop it." meant
with respect to this existing language.  Or perhaps I have not applied
the "delta emails" correctly and this text has already been dropped?

From draft-ietf-pkix-new-part1-05.txt, section 5.2.4 :

     If a CA supports the certificateHold revocation reason the
     following rules must be applied when generating delta CRLs:
     (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), whose cRLNumber
         is n, and the hold is subsequently released, the certificate
         must be included in all delta CRLs issued after the hold is
         released where the cRLNumber of the referenced base CRL is
         less than or equal to n. The certificate must be listed with
         revocation reason removeFromCRL unless the certificate is
         subsequently revoked again for one of the revocation reasons
         covered by the delta CRL, in which case 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 on all subsequent delta CRLs
         where the cRLNumber of the referenced base CRL is less than the
         cRLNumber of the CRL (either a delta CRL or a CRL that is complete
         for the given scope) on which the permanent revocation notice first
         appeared.

Regards,

Carlin

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Friday, May 04, 2001 10:30 AM
To: Carlin Covey
Cc: [email-masked]
Subject: RE: Certificate Hold (was RE: delta CRLs)

Clear?

Russ

---

From: Stephen Kent <[email-masked]>
Date: Fri, 4 May 2001 14:42:33 -0400

At 1:30 PM -0400 5/4/01, Housley, Russ wrote:
>I have NEVER liked the on-hold feature.  I still do not like the 
>on-hold feature.
>
>I will not delay the Last Call process on son-of-rfc 2459 to debate 
>the issue unless I see that there are others that support my view.

I feel the same as Russ, i.e., have never liked it and still think 
it's a bad idea. Since we deprecated the hold instruction (vis our 
comments on the hold instruction code entry extension) last time, is 
there are basis for change this time around?

Steve

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 04 May 2001 14:58:58 -0400

>the "delta emails" correctly and this text has already been dropped?

My "drop it" referred to the discussion on the mail list.

Russ