Subject: 3280bis: CRL validation: treatment of critical CRL entry extensions

From: Denis Pinkas <[email-masked]>
Date: Mon, 11 Jul 2005 13:33:16 +0200

3280bis: CRL validation: treatment of critical CRL entry extensions

RFC 3280 states on page 60 :

" 5.3  CRL Entry Extensions

   [...]

   All CRL entry extensions used in this specification are non-critical."

This is however untrue since RFC 3280 states on page 62 :

" 5.3.4  Certificate Issuer

   This CRL entry extension identifies the certificate issuer associated
   with an entry in [...] a CRL that has the indirectCRL indicator set
   in its issuing distribution point extension.
  
[...]

   If used by conforming CRL issuers, this extension MUST always be
   critical."

The text is unclear about what to do with a critical CRL entry extension
that is not recognized, and thus this needs to be clarified.

CRL entry extensions did not existed originally in CRL version v1 and could
be ignored when parsing a CRL. When introducing CRL entry extensions, the
idea was the following: if a given CRL entry is found to be "appropriate"
THEN and only THEN there is the need to make sure that it contains no
critical CRL entry extension that is not understood. If it does then the
CRL entry MUST be considered as invalid.

The problem is that, later on, a specific critical CRL entry extension has
been introduced: the Certificate Issuer CRL entry extension. That CRL entry
extension is very special since its presence in a CRL entry extension
earlier in the list of CRL entries modifies the meaning the CRL entry,
even if it does not contain a CRL entry extension.

This problem was however addressed by RFC 3280 since RFC 3280
states on page 59:

"The CRL issuer MUST assert the indirectCRL boolean, if the scope of
the CRL includes certificates issued by authorities other than the
CRL issuer.  The authority responsible for each entry is indicated
by the certificate issuer CRL entry extension (section 5.3.4)".

These two sentences are within the same paragraph, just one after
the other.

In the first sentence, the plural is used for "authorities" and thus
the first sentence is NOT written as follows : "The CRL issuer MUST
assert the indirectCRL boolean, if the scope of the CRL includes
certificates issued by *an authority* other than the CRL issuer".

The two sentences from page 59 from RFC 3280 would need to be
corrected in the following way:

"The CRL issuer MUST assert the indirectCRL boolean, if the scope of
the CRL includes certificates issued by *more than one certificate
issuer*. In such a case, the certificate issuer responsible for each
entry is indicated by the certificate issuer CRL entry extension
(section 5.3.4)".

These sentences indicate that, if the indirectCRL boolean is set to
TRUE, then one or more certificate issuer CRL entry extensions are
present.

This also means that if the IDP extension is not present or if the
indirectCRL boolean is set to FALSE, then no certificate issuer CRL
entry extension is present.

The indirectCRL boolean indicates the presence or absence of
certificate issuer CRL entry extensions in the CRL.

It allows to perform an efficient checking of the CRL entries :

 -    If the indirectCRL boolean is set to TRUE, then the CRL entry
      extensions from previous CRL entries MUST be checked to verify
      whether a certificate issuer CRL entry extension is present.

-     If the IDP extension is not present or if the indirectCRL boolean
      is set to FALSE, then CRL entry extensions from every CRL entry
      can ignored or skipped.

The core of the issue is about the following paragraph in section
6.3.3 on page 84 :

      (1)  If the DP includes cRLIssuer, then verify that the issuer
      field in the complete CRL matches cRLIssuer in the DP and that
      the complete CRL contains an issuing distribution point
      extension with the indrectCRL boolean asserted.  Otherwise,
      verify that the CRL issuer matches the certificate issuer.

BTW, there is a typo error where "indirectCRL" is typed
"indrectCRL".

Note that the current text in section 6.3.3 from RFC 3280 does not
handle the Certificate Issuer CRL entry extension, when present,
which may lead to incorrect results.

When the DP includes the cRLIssuer field, verifying that *one value*
from the issuer field in the complete CRL matches cRLIssuer in the
DP is both necessary and sufficient.

There is no need to have the following insertion :

                                                      " and that
         the complete CRL contains an issuing distribution point
         extension with the indirectCRL boolean asserted ".

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 11 Jul 2005 10:37:09 -0400

Denis,

Please see responses in-line under [Santosh:]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Monday, July 11, 2005 7:33 AM
To: pkix
Subject: 3280bis: CRL validation: treatment of critical CRL entry extensions

   [...]

  
[...]

CRL entry extensions did not existed originally in CRL version v1 and could
be ignored when parsing a CRL. When introducing CRL entry extensions, the
idea was the following: if a given CRL entry is found to be "appropriate"
THEN and only THEN there is the need to make sure that it contains no
critical CRL entry extension that is not understood. If it does then the CRL
entry MUST be considered as invalid.

The problem is that, later on, a specific critical CRL entry extension has
been introduced: the Certificate Issuer CRL entry extension. That CRL entry
extension is very special since its presence in a CRL entry extension
earlier in the list of CRL entries modifies the meaning the CRL entry, even
if it does not contain a CRL entry extension.

This problem was however addressed by RFC 3280 since RFC 3280 states on page
59:

"The CRL issuer MUST assert the indirectCRL boolean, if the scope of the CRL
includes certificates issued by authorities other than the CRL issuer.  The
authority responsible for each entry is indicated by the certificate issuer
CRL entry extension (section 5.3.4)".

These two sentences are within the same paragraph, just one after the other.

In the first sentence, the plural is used for "authorities" and thus the
first sentence is NOT written as follows : "The CRL issuer MUST assert the
indirectCRL boolean, if the scope of the CRL includes certificates issued by
*an authority* other than the CRL issuer".

The two sentences from page 59 from RFC 3280 would need to be corrected in
the following way:

"The CRL issuer MUST assert the indirectCRL boolean, if the scope of the CRL
includes certificates issued by *more than one certificate issuer*. In such
a case, the certificate issuer responsible for each entry is indicated by
the certificate issuer CRL entry extension (section 5.3.4)".

[Santosh: Denis has incorrect understanding of how indirect CRLs work.
First, the standard permits an indirect CRL issuer cover certificates issued
by a single CA.  Second, the second sentence above is worded such that it
could be misinterpreted to mean that each entry needs to assert the
certificate issuer.  That also is not true.]

These sentences indicate that, if the indirectCRL boolean is set to TRUE,
then one or more certificate issuer CRL entry extensions are present.

[Santosh: This statement is also incorrect.  Let us say that an indirect CRL
covers 1 or more CAs other than itself.  If none of the certificates issued
by those other CAs are revoked, none of the CRL entries will have the
certificate issuer present.]

This also means that if the IDP extension is not present or if the
indirectCRL boolean is set to FALSE, then no certificate issuer CRL entry
extension is present.

[Santosh: This is true.]

The indirectCRL boolean indicates the presence or absence of certificate
issuer CRL entry extensions in the CRL.

[Santosh: This is poorly worded.  If the indirect CRL flag is set,
certificate issuer extension may be present, but need not be present.  It is
also not clear why relying parties will care for many of the assertions made
by Denis.  We have a well-defined state machine for CRL and indirect CRL
processing.  It is best that the relying parties implement that and not add
other rules to make their software more complex.  For example, a somewhat
related problem I am uncovering is that some relying party software that
process extensions such as "inhibit any policy" are checking the criticality
of the extension.  Of course, that is useless.]

[Santosh: A proper way to process an indirect CRL is to apply the
certificate issuer state machine for the indirect CRL and it requires you to
process the entries in sequence]  

[Santosh: Again, assuming not using some the entry ordering extensions, you
need to go through all the entries and match the serial number.]

The core of the issue is about the following paragraph in section 6.3.3 on
page 84 :

[Santosh: The above statement in 3280 is correct]

BTW, there is a typo error where "indirectCRL" is typed "indrectCRL".

Note that the current text in section 6.3.3 from RFC 3280 does not handle
the Certificate Issuer CRL entry extension, when present, which may lead to
incorrect results.

When the DP includes the cRLIssuer field, verifying that *one value* from
the issuer field in the complete CRL matches cRLIssuer in the DP is both
necessary and sufficient.

[Santosh: You also want to make sure that the CRL is indirect CRL since the
crlIssuer in the CRL DP in certificate implies that the CRL issuer is some
one other than certificate issuer.  Please see section 4.2.1.14 of RFC 3280]

                                                      " and that

[Santosh: See my previous comment.]
Denis

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 11 Jul 2005 11:28:41 -0400

>   All CRL entry extensions used in this specification are non-critical."

Already changed in 3280bis-00.

> CRL entry MUST be considered as invalid.

Yes.  There is a sentence in clause 7.3 of X.509 that states something 
to this effect, but the rule was violated with the certificateIssuer 
extension.  We have submitted a defect report, DR 311 
(ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_311.pdf), 
to have this sentence removed from X.509.

> certificates issued by *an authority* other than the CRL issuer".

As has been stated many times, the indirectCRL boolean is asserted if 
the scope of the CRL includes one or more certificates  for which the 
issuer field in the certificate is different from the issuer field in 
the CRL.  We cannot change that.  However, if the use of the term 
"authorities" is truly causing confusion, we can change that.  How about:

      If the scope of the CRL only includes certificates issued by the CRL
      issuer then the indirectCRL boolean MUST be set to FALSE.  Otherwise,
      if the scope of the CRL includes certificates issued by one or more
      authorities other than the CRL issuer, the indirectCRL boolean MUST
      be set to TRUE.  The authority responsible for each entry is
      indicated by the certificate issuer CRL entry extension (section
      5.3.4).

> TRUE, then one or more certificate issuer CRL entry extensions are

While this is usually the case, is not may always be.   The indirectCRL 
boolean is set to TRUE if the SCOPE of the CRL includes certificates 
issued by an authority (or authorities) other than the CRL issuer, but 
it may be that none of these certificates have been revoked.

If no certificates within the scope of the CRL have been revoked, then 
revokedCertificates will be absent, but the indirectCRL could still be 
asserted.  Similarly, if the only revoked certificates within the scope 
of the CRL are certificates issued by the CRL issuer, then the 
certificateIssuer CRL entry extension does not need to appear in any of 
the CRL entries since  section 5.3.4 states:

      If [the certificate issuer] extension is not present on the first 
entry in an
      indirect CRL, the certificate issuer defaults to the CRL issuer.  On
      subsequent entries in an indirect CRL, if this extension is not 
present,
      the certificate issuer for the entry is the same as that for the 
preceding entry.

If the certificateIssuer CRL entry extension is not included in any of 
the CRL entries, then the certificate issuer associated with each entry 
will be the issuer of the CRL.  So, if all revoked certificates were 
issued by the issuer of the CRL, then the certificateIssuer CRL entry 
extension does not need to be included in any CRL entries even if the 
scope of the CRL includes certificates that were not issued by the 
issuer of the CRL.

> BTW, there is a typo error where "indirectCRL" is typed

Fixed.

> which may lead to incorrect results.

In section 6.3.3, steps (i) and (j) refer to section 5.3.4.  Section 
5.3.4 specifies how to determine the certificate issuer associated with 
each entry in the CRL.

>         extension with the indirectCRL boolean asserted ".

This step is a necessary part of determining whether the certificate is 
included in the scope of the CRL.  If the indirectCRL boolean is not 
asserted then the CRL does not cover any certificates for which the 
issuer name in the certificate is different from the issuer name in the 
CRL.  So, if you are using a CRL to determine the status of a 
certificate, and the issuer names are not the same, you must verify that 
indirectCRL boolean is asserted in the CRL in addition to verifying that 
the CRL issuer's name appears in the cRLIssuer field in the description 
of the distribution point in the certificate.

Dave

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 15 Jul 2005 10:20:48 +0200

Santosh,

>certificate issuer.  That also is not true.]

You missed the "s" from the word "authority". You also missed the point
that a CRL issuer cannot issue certificates, unless it is also the CA.
See my last response to David.

>certificate issuer present.]

Let us say that the boolean should indicate the presence of
certificates from multiples CAs. The wording "delegated" CRL should be
used when the CRL covers certificates from a single CA. See my response
to David.

>of the extension.  Of course, that is useless.]

The current processing rules are too complex and do not cover clearly
what "conforming relying parties" MUST support when handling CRLs,
I mean relying parties supporting the mandatory-to-support extensions
for relying parties.

The text needs also to be clear about what additional treatments MAY be
supported.

The current algorithm from section 3280bis is also based on unsufficient
assumptions, I would even say "incorrect assumptions". There is no
mention when the cache is flushed  so it may contain multiples CRLs:
"old" CRLs which are useful to demonstrate that a certificate is revoked
when the "valid" CRL is not available.

The current algorithm does not also support the case where two or more
"valid" CRLs are present in the cache, or said in different words:
may provide a wrong output in that case.

The last I-D that I have posted takes care of all of these cases.
It is available at:
http://www.ietf.org/internet-drafts/draft-pinkas-pkix-conf-crl-validation-01.txt

>      is set to FALSE, then CRL entry extensions from every CRL entry

Not necessarily. This can be done backwards. See my proposal in :
http://www.ietf.org/internet-drafts/draft-pinkas-pkix-conf-crl-validation-01.txt

>need to go through all the entries and match the serial number.]

No. There is no need to go through every entry to check if the very
specific certificate issuer crl entry extension is present in a crl
entry. This can be done backwards. See my proposal in :
http://www.ietf.org/internet-drafts/draft-pinkas-pkix-conf-crl-validation-01.txt
which avoids to test *every* crl entry extension.

>one other than certificate issuer.  Please see section 4.2.1.14 of RFC 3280]

It is fully sufficient to check that the CRL issuer name is different
from the certificate issuer name.

The presence or absence of the mis-named indirectCRL boolean from the
IDP extension is of no use at all from a relying party point of view.
See my proposal in :
http://www.ietf.org/internet-drafts/draft-pinkas-pkix-conf-crl-validation-01.txt

Now, if  you can demonstrate that in case the CRL contains only
certificates issued by one CA, there would be some fraud possible in the
absence of the boolean, then I would be interrested to examine how.

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 15 Jul 2005 10:17:22 +0200

David,

> to have this sentence removed from X.509.

The defect report that has been submitted does not solve the issue.
First it is incorrect because the first sentence of note 5 is related
to CRL extensions, but not CRL entry extensions, and thus does not need
to be deleted.

Second: the note 4 remains. It is copied below:

    When an implementation processing a certificate revocation list does
    not recognize a critical extension in the *crlEntryExtensions* field,
    it shall assume that, at a minimum, the identified certificate has
    been revoked and is no longer valid and perform additional actions
    concerning that revoked certificate as dictated by local policy.
    When an implementation does not recognize a critical extension
    in the *crlExtensions* field, it shall assume that identified
    certificates have been revoked and are no longer valid.

You want to change the general rule and thus you want to delete the
note 5, but note 4 still remains.

The other way is to maintain the general rule (as it is explained in
note 4) and to adress the exception, i.e. how to deal with the
certificate issuer crl entry extension.

But we are are revising 3280 and the point is that there is no guidance
at all in RFC 3280 to know what a relying party should do with a
critical crl entry extension. We need text for the general rule and we
need text to handle the (single one) exception.

> the CRL.  We cannot change that.  

The current text is as follows:

RFC 3280 states:

« Whenever the CRL issuer is not the CA that issued the certificates,
   the CRL is referred to as an indirect CRL ».

This sentence means that an indirect CRL is not issued by an entity that
has issued the certificate.

This comes into conflict with the following sentence extracted from
section 5.3.4 Certificate Issuer :

    If this extension is not present on the first entry in an
    indirect CRL, the certificate issuer defaults to the CRL issuer.

For an indirect CRL, the certificate issuer cannot default to the name
of the CRL issuer since the CRL issuer has not issued any of the
certificates that are in the indirect CRL. This would only be the case
when the CRL is a “direct CRL”.

The current text of RFC 3280 is inconsistent.

The fact is that when a CRL is about certificates issued by more than
one CA, the certificate issuer CRL entry extension MUST be present,
whereas when a CRL is about certificates issued by only one CA, it is
unnecessary to use the certificate issuer CRL entry extension but it
were present this would not heart since the algorithm to be used by
relying parties to verify CRLs would not need to make use of it. This
opens the road for backwards compatibility, if necessary.

This also means that when an indirect CRL is related to certificates
from more than one CA, the certificate issuer CRL entry extension MUST
be present on the first entry in an indirect CRL,   ... which is
obviously in full contradiction with the current text from RFC 3280.

In addition, the end of section 5.3.4 is incorrect as already mentioned
in earlier e-mails. Itis copied again below:

    If used by conforming CRL issuers, this extension MUST always be
    critical.  If an implementation ignored this extension it could not
    correctly attribute CRL entries to certificates.  This specification
    RECOMMENDS that implementations recognize this extension.

Section 5.3.4 needs to be fully revised.

My interpretation of the boolean would be:

    "The CRL issuer MUST assert the indirectCRL boolean, if the scope
     of the CRL includes certificate serial numbers in the
     revokedCertificates list for which the issuer names are different.

…or an alternative sentence which means the same:

    "The CRL issuer MUST assert the indirectCRL boolean, if the scope
     of the CRL includes certificate serial numbers in the
     revokedCertificates list from more than one CA.

If we keep the name of the boolean, then we should restrict the use of
the wording "indirect CRLs" to CRLs that contain serial numbers from
more than one CA.

The text from RF 3280 should then be changed into:

   " Whenever the CRL issuer is not the CA that issued the certificates,
   the CRL is referred to as a delegated CRL, if it contains certificates
   from a single CA, or as an indirect CRL when it may contain
   certificates from multiple CAs ".

Now, if the CRL is NOT issued by a CA and includes certificates from a
single CA, the certificate issuer CRL entry extension is unnecessary
since the name of the issuer is not taken from the name of the issuer in
the CRL, neither from any value of the certificate issuer CRL entry
extension, if present, but simply from the issuer name of the certificate.

Of course, there is also the need to add in 3280bis an adaptation of the
text of the security consideration section from
<draft-pinkas-pkix-conf-crl-validation-01.txt>:

    A CRL Issuer SHALL not accept the duty to issue CRLs for one CA,
    if it has already agreed to perform that task for another CA that
    has the same DN.

RFC3280 has problems of inconsistencies that need to be solved.

BTW, since I followed too closely the text from section 5.3.4, some text
of section the 6.3.3.3 of
<draft-pinkas-pkix-conf-crl-validation-01.txt> needs to be revised. The
correction is posted in a separate e-mail.

> However, if the use of the term

You know that we will never agree on that kind of statement since
"certificates issued by [whatever] *other than the issuer CRL*" is
unacceptable since a CRL issuer never issues CRLs, unless it also a CA.

> While this is usually the case, is not may always be.   The 
> indirectCRL boolean is set to TRUE if the SCOPE of the CRL includes 
> certificates issued by an authority (or authorities) other than the 
> CRL issuer, but it may be that none of these certificates have been 
> revoked.

The plural is used, i.e. "authorities. "authority" is NOT used. The text
is NOT "authority (or authorities)" as you would like it to be.

> asserted.  Similarly, if the only revoked certificates within the 
> scope of the CRL are certificates issued by the CRL issuer, then the 
> certificateIssuer CRL entry extension does not need to appear in any 
> of the CRL entries since  section 5.3.4 states:

> the CRL entries, then the certificate issuer associated with each 
> entry will be the issuer of the CRL.  So, if all revoked certificates 
> were issued by the issuer of the CRL, then the certificateIssuer CRL 
> entry extension does not need to be included in any CRL entries even 
> if the scope of the CRL includes certificates that were not issued by 
> the issuer of the CRL.

See above.

> Fixed.

Fine. At least one issue on which we agree. :-)

> 5.3.4 specifies how to determine the certificate issuer associated 
> with each entry in the CRL.

This far from sufficient see my *new* I-D (version -01) that has been
published:
http://www.ietf.org/internet-drafts/draft-pinkas-pkix-conf-crl-validation-01.txt

It takes care in great details about the treatment of that specific crl
entry extension.

> This step is a necessary part of determining whether the certificate 
> is included in the scope of the CRL.  

This step is fully unnecessary if the scope of the CRL includes
certificates from only one CA.

Denis

> If the indirectCRL boolean is 
> not asserted then the CRL does not cover any certificates for which 
> the issuer name in the certificate is different from the issuer name 
> in the CRL.  So, if you are using a CRL to determine the status of a 
> certificate, and the issuer names are not the same, you must verify 
> that indirectCRL boolean is asserted in the CRL in addition to 
> verifying that the CRL issuer's name appears in the cRLIssuer field in 
> the description of the distribution point in the certificate.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 15 Jul 2005 13:01:21 -0400

Denis,

Please see responses in-line in [Santosh2:] with irrelevant material
deleted.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Friday, July 15, 2005 4:21 AM
To: Santosh Chokhani
Cc: 'pkix'
Subject: Re: 3280bis: CRL validation: treatment of critical CRL entry
extensions

>The problem is that, later on, a specific critical CRL entry extension 
>the CRL includes certificates issued by authorities other than the CRL 
>issuer.  The authority responsible for each entry is indicated by the 
>certificate issuer CRL entry extension (section 5.3.4)".
>
>The two sentences from page 59 from RFC 3280 would need to be corrected 
>in the following way:
>

>First, the standard permits an indirect CRL issuer cover certificates 
>issued by a single CA.  Second, the second sentence above is worded 
>such that it could be misinterpreted to mean that each entry needs to 
>assert the certificate issuer.  That also is not true.]

You missed the "s" from the word "authority". You also missed the point that
a CRL issuer cannot issue certificates, unless it is also the CA. See my
last response to David.

[Santosh2: I am sure I have missed a lot.  But, that is not the point of
discussion.  Let us get back to the point of discussion and that is the
language proposed by Denis, which is wrong.  The standard permits an
indirect CRL to cover certificates issued by a single CA.  Denis's proposal
prohibits and hence changes the standard.  Furthermore, there is no security
or interoperability need to change the standard.  Thus, Denis's proposed
change must be rejected.] 

>[Santosh: This statement is also incorrect.  Let us say that an 
>indirect CRL covers 1 or more CAs other than itself.  If none of the 
>certificates issued by those other CAs are revoked, none of the CRL 
>entries will have the certificate issuer present.]

Let us say that the boolean should indicate the presence of certificates
from multiples CAs. The wording "delegated" CRL should be used when the CRL
covers certificates from a single CA. See my response to David.

[Santosh2: Again, Denis's language is incorrect and he has not responded to
my response.  To repeat, just because there is an indirect CRL, does not
mean, that it will have any entries at all or from any of the CAs.  So
Denis's statement is false.  Even if started rising in the West and Denis's
statement were to be true, it would be useless from relying party
perspective.  We have a well defined algorithm for CRL processing and it
provides no security or interoperability benefit that a relying party check
that if indirect CRL flag is set, there are some certificateIssuer CRL entry
extensions.  This will be a useless and erroneous check.] 

>certificate issuer extension may be present, but need not be present.  
>It is also not clear why relying parties will care for many of the 
>assertions made by Denis.  We have a well-defined state machine for CRL 
>and indirect CRL processing.  It is best that the relying parties 
>implement that and not add other rules to make their software more 
>complex.  For example, a somewhat related problem I am uncovering is 
>that some relying party software that process extensions such as 
>"inhibit any policy" are checking the criticality of the extension.  Of 
>course, that is useless.]

The current processing rules are too complex and do not cover clearly what
"conforming relying parties" MUST support when handling CRLs, I mean relying
parties supporting the mandatory-to-support extensions for relying parties.

The current algorithm from section 3280bis is also based on unsufficient
assumptions, I would even say "incorrect assumptions". There is no mention
when the cache is flushed  so it may contain multiples CRLs: "old" CRLs
which are useful to demonstrate that a certificate is revoked when the
"valid" CRL is not available.

The current algorithm does not also support the case where two or more
"valid" CRLs are present in the cache, or said in different words: may
provide a wrong output in that case.

The last I-D that I have posted takes care of all of these cases. It is
available at:
http://www.ietf.org/internet-drafts/draft-pinkas-pkix-conf-crl-validation-01
.txt

[Santosh2: Without going into complexity of current rules, the rules
proposed by Denis's are neither needed, nor accurate, not provide any
security benefit.  In short, they have no purpose.  At least the so called
"complex rules" have a purpose.  As to the new I-D, Denis's posting have one
common theme: they exhibit a lack of understanding of the CRL mechanism and
CRL processing rules.  It is not clear what benefit reviewing an I-D would
make when author's posting exhibit lack of understanding of the topic which
the I-D covers.]

>certificate issuer state machine for the indirect CRL and it requires 
>you to process the entries in sequence]
>

Not necessarily. This can be done backwards. See my proposal in :
http://www.ietf.org/internet-drafts/draft-pinkas-pkix-conf-crl-validation-01
.txt

>[Santosh: Again, assuming not using some the entry ordering extensions, 
>you need to go through all the entries and match the serial number.]

No. There is no need to go through every entry to check if the very specific
certificate issuer crl entry extension is present in a crl entry. This can
be done backwards. See my proposal in :
http://www.ietf.org/internet-drafts/draft-pinkas-pkix-conf-crl-validation-01
.txt
which avoids to test *every* crl entry extension.

[Santosh2: You can do what ever you want, but the state machine remains the
same: certificate_issuer  = value in the CRL entry extension and if the
extension is absent, certificate_issuer = certificate_issuer_state;
certificate_issuer_state = certificate_issuer.  This state machine must be
executed in sequence starting with the first entry and the initial value of
certificate_issuer_state = issuer field in the CRL.  If you want to come to
US from France via Asia and pacific ocean, feel free.]

>from the issuer field in the complete CRL matches cRLIssuer in the DP 
>is both necessary and sufficient.

>[Santosh: You also want to make sure that the CRL is indirect CRL since 
>the crlIssuer in the CRL DP in certificate implies that the CRL issuer 
>is some one other than certificate issuer.  Please see section 4.2.1.14 
>of RFC 3280]

It is fully sufficient to check that the CRL issuer name is different from
the certificate issuer name.

[Santosh2: No.  You want to make sure that when they are different, the CRL
is truly an indirect CRL and you do not get a direct CRL from the CRL issuer
who can be CA.]

The presence or absence of the mis-named indirectCRL boolean from the IDP
extension is of no use at all from a relying party point of view. See my
proposal in :
http://www.ietf.org/internet-drafts/draft-pinkas-pkix-conf-crl-validation-01
.txt

Now, if  you can demonstrate that in case the CRL contains only certificates
issued by one CA, there would be some fraud possible in the absence of the
boolean, then I would be interrested to examine how.

Denis