Subject: RE: Last Call: draft-ietf-pkix-new-part1-06.txt comments

From: Sharon Boeyen <[email-masked]>
Date: Wed, 18 Apr 2001 13:30:12 -0400

The cRLSign bit should be restricted to verifying signatures on 
CRLs (not on other types of revocation status information) regardless
of who issues the CRLs.

On that topic, the 509 intent was that either the issuer of a certificate
or an entity authorized (to issue indirect CRLs) by the issuer of the
certificate would issue the 
relevant CRL(s) for that certificate. That intent applies to both public-key
and attribute certificates. 

Russ, when I reviewed your text, only one point came to mind. There are 
cases where a single authority will act as both a CA for public-key
certificates
and an AA for attribute certificates. As such, it would issue CRLs for the 
public-key certs and CRLs for the attribute certs. If I'm interpreting your 
text correctly, you would not permit the same certificate to indicate both?

Incidentally I just noticed another editorial correction that will need to 
be made to 509 to correctly indicate that both CAs and AAs can sign CRLs. In
the text for 
the cRLSign bit in the keyUsage extension (clause 8.2.2.3),
"for verifying a CA's signature" should read "for verifying an authority's
signature", in 
line with the editorial changes I made throughout 509 as mentioned in an
earlier message. 
This one was missed. 

Sharon  

> -----Original Message-----
> From: Marc Branchaud [mailto:[email-masked]]
> Sent: Wednesday, April 18, 2001 12:36 PM
> To: [email-masked]
> Subject: Re: Last Call: draft-ietf-pkix-new-part1-06.txt comments
> 
> 
> 
> Jim Schaad wrote:
> > 
> > 2.  This text implies to me that the cRLSign bit must be 
> set for an OCSP
> > responder (it does revocation information) is that what you want?
> > 
> 
> The way I read it, the bit can only be set for OCSP 
> responders that serve
> status for non-public-key certs.  In other words, the cRLSign 
> bit MUST NOT be
> asserted in all deployed OCSP responder certs.  (AFAIK, there 
> are no OCSP
> responders currently serving status on attribute certs, 
> though it certainly
> would be easy for them to do so.)  OTOH, the CRLSign bit MAY 
> be asserted for
> OCSP responders that _only_ serve status for non-public-key 
> certificates.  If
> an OCSP responder serves status for both types of 
> certificate, then I guess
> the bit would stay off...
> 
> Either way, the situation WRT OCSP responders is vague.  I 
> suggest that the
> first sentence be changed as follows:
> 
>    The cRLSign bit is asserted when the subject public key is 
> used for BOTH
>    verifying a signature on a certificate and for verifying a 
> signature on
>    revocation information (e.g., a CRL).
> 
> I think this aligns most closely with the intended use of the 
> bit, i.e. that
> it should only apply to entities that issue certificates.  
> Thus, a plain OCSP
> responder would not have the bit asserted in its cert.  But 
> if a CA or AA key
> is used to sign OCSP responses, then the bit SHOULD (MUST?) 
> be asserted in
> the CA/AA's cert.  To emphasize that, I recommend changing the second
> sentence to:
> 
>    This bit MUST be asserted in CA certificates that are used 
> to verify
>    signatures on CRLs and/or OCSP responses.
> 
> 		Marc
>

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 19 Apr 2001 17:32:35 +0200

One topic per message: This one about delta-CRLs (section 5.2.4).

In the third paragraph the first sentence (still) says:

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

1) There has been a thread on the mailing list where I understand that 
   the conclusion was that a "MUST" was not appropriate and should either 
   be replaced by a "SHOULD" or even the whole sentence should been deleted.

2) The text is also misleading while speaking of "the" delta-CRL since at
   one time there will be many delta-CRLs in a repository and the basic 
   question is to know which one to use. The document offers no guidance on 
   that topic, but it should.

3) The text says:

   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.

 a) It is hard to understand in which case the base CRL may have a 
    cRLNumber *greater than* the cRLNumber of the base CRL referenced 
    in the delta CRL. I certainly miss something here. The equality case
    is easy to understand. The "greater than" case is much harder. 
    Is it really needed ?

 b) the case of a locally constructed CRL is quite stange and it is 
    questionnable why this case is being mentioned. In the following fix, 
    that case has been deleted.

4) The FreshestRL extension is described without sufficient explanations
   to understand the use of that extension. So I propose the following 
   for section 5.2.6. Add : 

   "This extension MUST be present when a delta CRL mechanism is
    supported for that CRL."

To solve the first three concerns I propose to replace the third and fourth
paragraphs of section 5.2.4. by :

   The Delta CRL Indicator in a delta CRL and the CRL number from 
   a complete CRL MUST contain the same value so that they can be 
   associated. When a delta CRL is issued, it MUST cover the same
   set of reasons and the same set of certificates that were covered 
   by the base CRL it references.
 
   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; or

... then the text continues with:

   The constructed CRL has the CRL number specified in the CRL number
   extension found in the delta CRL used in its construction.

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

Since I have had private exchanges with both Tim Polk and David Cooper
from NIST, on that topic the following explanations are primarily for them:

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 ?

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. So only the other case remains: when a base CRL is issued an usually 
empty delta CRL must also be issued. At a first glance this does not seem to 
be optimum, but it is ! The algorithm remains unchanged whatever the time of
the day may be. When a base CRL contains the freshest CRLextension this
means that a delta mechanism is supported. If the application is wishing to
take advantage of the freshest information, then it MUST find a CRL where
both the delta refers to that CRL number and where the current date is
between thisUpdate and nextUpdate.

An alternative would be to support another extension saying "by the way, do
not look for any delta during the next hour". This is a solution that we 
should not promote for three good reasons:

1° this is yet-another-extension;
2° this changes the basic algorithm;
3° the optimization would be for the first delta only. If a delta is issued 
   every hour and a base once a day, then the optimization is only for one 
   hour (e.g. between midnight and one o'clock) and not for the remaining 
   23 hours.

Regards,

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 19 Apr 2001 17:45:55 +0200

One topic per message: This one about applying constraints to the path
validation algorithm.

In section 6.2 we now have:

   The path validation algorithm describes the process of validating a
   single certification path.  While each path begins with a specific
   trust anchor, there is no requirement that all paths validated by a
   particular system share a single trust anchor.  An implementation
   that supports multiple trust anchors may augment the algorithm
   prresented in section 6.1 to further limit the set of valid paths

...Please a single r for prresented.

   which begin with a particular trust anchor.  For example, an
   implementation may specify name constraints that apply to a specific
   trust anchor.

While the sentence is true in the case of multiple trust anchors it is as
well valid for a single one. So a similar sentence is needed in section 6.1.

In section 6.1 the text says:

   A particular certification path may not, however, be appropriate for
   all applications.  The path validation process also determines the
   set of certificate policies that are valid for this path, based on
   the certificate policies extension, policy mapping extension, policy
   constraints extension, and inhibit any-policy extension. 

The text should rather say:

   An application may augment the algorithm presented in section 6.1
   to further limit the set of valid paths. For example, an
   implementation may specify additional constraints like name 
   constraints or specific extensions that apply to the application. 
   Therefor the conditions which are described in this section are 
   minimum conditions. The path validation process described in this 
   section determines the minimum conditions that are to be fulfilled 
   by the certification path for the set of certificate policies 
   that are valid for this path, based on the certificate policies 
   extension, policy mapping extension, policy constraints extension, 
   and inhibit any-policy extension, as well as for the name 
   constraints, if any. 

The main difference between 6.1 and 6.2 is that the additional contraints
(policy or name constraints) apply globally to the path validation algorithm
when there is one trust anchor (6.1), but may apply on every trust anchor
where there are multiple trust anchors (6.2).

Denis

---

From: Steve Hanna <[email-masked]>
Date: Thu, 19 Apr 2001 12:26:03 -0400

It is certainly true that specifying name constraints for trust anchors
will work when a single trust anchor is used. Perhaps the sentence in
section 6.2 should be changed to say "Implementations may also augment
the algorithm presented in section 6.1 to further limit the set of valid
paths which begin with a particular trust anchor."

However, I object to adding support for limits on trust anchors to
section 6.1. The algorithm in section 6.1 is the "basic" algorithm that
everyone MUST implement. Section 6.2 describes various ways to extend
that algorithm. Multiple trust anchors is one. Limits on trust anchors
is a second. PEM compatible processing is a third. If one argues that
limits on trust anchors should be described in section 6.1, one could
equally argue that PEM compatible processing should be described in
section 6.1.

-Steve

---

From: "David P. Kemp" <[email-masked]>
Date: Thu, 19 Apr 2001 12:28:55 -0400

>     that case has been deleted.

Denis,

The case of a locally-constructed CRL is necessary, and must not be
forbidden.  If you assume:

 1) certificates are valid for two years
 2) delta CRLs are issued every hour
 3) delta CRLs are based on the most recently issued full CRL
 4) relying parties download every full CRL

and calculate revocation bandwidth as a function of full CRL issuance
period, you will find that the minimum bandwidth occurs at some very long
interval (greater than 30 days).  This is because full CRLs are much
larger than deltas, and as the interval goes up, the bytes per day of
full CRLs goes down and the bytes per day for deltas goes up, until they
are balanced.

If you discard assumption 4 and allow relying parties to construct a
running revocation state database exclusively from delta CRLs, the
minimum bandwidth occurs at a much shorter interval (one hour in the limit,
but 24 hours may be acceptably close to the minimum).  Depending on
CRL population and revocation rate, the bandwidth difference between
delta+full and delta-only can be several orders of magnitude.

Relying parties must be permitted to maintain revocation state using
only delta CRLs and (very) infrequent full CRLs.

Dave

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 19 Apr 2001 12:47:31 -0400

Denis,

There seems to be some confusion about the way that delta-CRLs work. I will try to clarify things with my responses in-line below.

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

I must admit that I am not a big fan of this requirement. From my point of view, there are both advantages and disadvantages to issuing a full CRL whenever a delta-CRL is issued. The advantage is that clients that can not process delta-CRLs can always obtain the same status information as those than can process delta-CRLs. The disadvantage is that it imposes a burden of uploading full CRLs to repositories more often than may be necessary. On the other hand, just because the CA issues the full CRLs, this does not mean that clients must retrieve them.

In the end, though, it is mostly a policy decision. If you want to provide the same support to clients that can not process delta-CRLs as to those that can, you must issue a full CRL whenever you issue a delta-CRL. I think the decision should be left to CRL issuers, but will not complain if PKIX remains as it is.

>     that case has been deleted.

If you want a detailed description on this, you could read my paper on delta-CRLs, http://csrc.nist.gov/pki/documents/sliding_window.pdf, but I'll try to briefly explain here.

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 full CRL issued at midnight and the delta-CRL issued at 3:00am (CRL number 8). It would combine these to construct full CRL number 8. In this case, the CRL number of the full CRL used in combination with the delta-CRL would be the same as the BaseCRLNumber in that delta-CRL.

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.

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.

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

>should issue a delta and, if yes, does this delta refer to the previous

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

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

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 19 Apr 2001 19:03:03 +0200

Steve,
 
> equally argue that PEM compatible processing should be described in

I agree with the intent, but this is NOT what the text says. :-(

In particular section 6.1 only says " This text describes an algorithm for
X.509 path processing". It does not qualifies it as basic nor says that it
is a set of minimum conditions.  

Section 6.2 says " The path validation algorithm describes the process of
validating a single certification path".

Currently, the text for section 6.1. is for a single anchor while the text
for section 6.2 is for more than one anchor.

"An implementation that supports multiple trust anchors may augment the
algorithm presented in section 6.1 to further limit the set of valid paths
which begin with a particular trust anchor."

You are proposing that the text from section 6.1 describes the "basic"
algorithm, while the text from section 6.2. describes enhancements to the
basic algorihm. I would not be opposed to your proposal, ... but many text
changes would be required. 

Denis

---

From: Steve Hanna <[email-masked]>
Date: Thu, 19 Apr 2001 13:51:28 -0400

> is a set of minimum conditions.

Section 6 (third paragraph) says "In section 6.1, the text describes
basic path validation." A few paragraphs later, it says "Section 6.2
describes methods for using the path validation algorithm in specific
implementations. Two specific cases are discussed: the case where paths
may begin with one of several trusted CAs; and where compatibility with
the PEM architecture is required."

Section 6.1 (first paragraph) says "A conformant implementation MUST
include an X.509 path processing procedure that is functionally
equivalent to the external behavior of this algorithm." And section 6.1
is titled "Basic Path Validation", while section 6.2 is titled "Using
the Path Validation Algorithm".

That's why I said that section 6.1 is the "basic" algorithm that
everyone MUST implement and section 6.2 describes various ways to extend
that algorithm.

> which begin with a particular trust anchor."

This is one of several variations included in section 6.2. PEM
compatible processing is also included in section 6.2. Section 6.2 is
clearly not limited to variations which employ multiple trust anchors.

> changes would be required.

I don't think so. I think the text at the start of section 6 is clear.
Perhaps an introductory paragraph at the start of section 6.2 would make
it even clearer, but I don't see any other changes that would be
required.

-Steve

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 20 Apr 2001 18:50:06 +0200

> I must admit that I am not a big fan of this requirement. From my point of view, there are both advantages and disadvantages to issuing a full CRL whenever a delta-CRL is issued. The advantage is t…

[Denis] Since you are "not a big fan of this requirement" and no other fan
has been found up to now, let us suppress that sentence.

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

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

> 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 up…

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

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.

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.

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:

   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.

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

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

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.

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

> 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 cRL…

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

Regards,

Denis

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 20 Apr 2001 18:22:22 -0400

Denis,

My comments are in line.

>confusing between CRL numbers.

This is simply not true. A delta-CRL can (will) contain the cRLNumber extension just as a full CRL will. 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. 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. The delta-CRL should have the same cRLNumber as would have been assigned to a full CRL issued at the same time.

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.

>than making a simple addition.

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.

>reason this mechanism should be deprecated.

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.

>originally triggered all this discussion.

I don't understand this at all.

>nextUpdate. This is *very* important.

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. Since the cRLNumber of the base can be greater than the specified BaseCRLNumber, the document should say so. 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. 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.

>In either case this simply does not work.

Why? A delta-CRL must include a BaseCRLNumber that corresponds to a CRL that was issued at some time in the past.

>certificates who statuses have changed since the issuance of a specific,

Where is the difference? A CRL that is referenced in the BaseCRLNumber of a delta-CRL is by definition a base CRL.

>make choices among multiple methods, otherwise two different implementations

you say that you want to stick with "traditional" delta-CRLs, however you are proposing changes to the text that would not result in "tradtional" delta-CRLs but would result in broken implementations. We do not prevent people from implementing "traditional" delta-CRLs, but we should not force them to either. 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.

I want to be sure that the delta-CRL text is correct just as you do, but I still feel that many of your comments are based on a misunderstanding and are not based on actual problems in the text.

Dave

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 20 Apr 2001 16:25:57 -0400

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

Originally, this sentence was placed in RFC 2459 to ensure that simple 
clients are able to get the best possible revocation information.  We did 
not want to require CAs or clients to support delta-CRLs, but if a CA chose 
to support delta-CRLs, we did not want to penalize clients.

I do not see that either of these desires has changed.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 23 Apr 2001 15:05:58 +0200

Steve,

> basic path validation." 

OK. One point for you for the use of the word "basic", but ...

one point for me because the text does not say that it is a set of minimum
conditions. :-)

> A few paragraphs later, it says "Section 6.2

> everyone MUST implement and section 6.2 describes various ways to extend

 .. but the text does not say that it is a set of minimum conditions.
 
> > validating a single certification path".

.. but the text frpom section 6.1. does not say that other constraints may
be applied even when there is a single trust anchor.

> clearly not limited to variations which employ multiple trust anchors.

The only other case is PEM:

   It is also possible to specify an extended version of the above
   certification path processing procedure which results in default
   behavior identical to the rules of PEM [RFC 1422]. 

> it even clearer, but I don't see any other changes that would be

The case of a single anchor with additional constraints is still not covered
by the current text.

Regards,

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 23 Apr 2001 17:28:56 +0200

David,

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.

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

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.

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

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

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

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

> >certificates who statuses have changed since the issuance of a specific,
 
[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.
 
> >make choices among multiple methods, otherwise two different implementations
 
[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

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 24 Apr 2001 09:43:32 -0400

Denis:

I agree with Steve Hanna's observation.  However, I think that we can 
include a bit of notice in section 6.1.  I propose the following 
replacement paragraph:

    A particular certification path may not, however, be appropriate for
    all applications.  Therefore, an application MAY augment this
    algorithm to further limit the set of valid paths.  The path
    validation process also determines the set of certificate policies
    that are valid for this path, based on the certificate policies
    extension, policy mapping extension, policy constraints extension,
    and inhibit any-policy extension.  To achieve this, the path
    validation algorithm constructs a valid policy tree.  If the set of
    certificate policies that are valid for this path is not empty, then
    the result will be a valid policy tree of depth n, otherwise the
    result will be a null valid policy tree.

I suggest that we replace the first paragraph of section 6.2. with:

    The path validation algorithm describes the process of validating a
    single certification path.  While each certification path begins with
    a specific trust anchor, there is no requirement that all
    certification paths validated by a particular system share a single
    trust anchor.  An implementation that supports multiple trust anchors
    MAY augment the algorithm presented in section 6.1 to further limit
    the set of valid certification paths which begin with a particular
    trust anchor.  For example, an implementation MAY modify the
    algorithm to apply name constraints to a specific trust anchor during
    the initialization phase, or the application MAY require the presence
    of a particular alternative name form in the end entity certificate,
    or the application MAY impose requirements on application-specific
    extensions.  Thus, the path validation algorithm presented in section
    6.1 defines the minimum conditions for a path to be considered valid.

Russ