Subject: 3280bis: CRL validation: what is wrong and/or missing in section 6.3

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

3280bis: CRL validation: what is wrong and/or missing in section 6.3.

1. The very first sentence states:

 " This section describes the steps necessary to determine if a
   certificate is revoked or on hold status when CRLs are the revocation
   mechanism used by the certificate issuer".

a) This section should describe the steps necessary to determine
   if the revocation status of the certification path* is : REVOKED,
   NOT_REVOKED or UNKNOWN, instead of simply determine if the
   *target certificate* is REVOKED. So the sentence is incorrect.

b) The current text mentions the return of the "on hold" status.
   However since CRLreason is not mentioned as an output parameter
   of the algorithm, this may not be the case (the only algorithm
   output is currently the revocation status of the certificate).

2. The text states: " Conforming implementations that support
CRLs are not required to implement this algorithm, but they MUST
be functionally equivalent to the external behavior resulting
from this procedure".

This sentence is incorrect since the algorithm would mandate
the support of many certificate extensions, CRL extensions and
CRL entry extensions that conforming relying party applications
are NOT REQUIRED to support. The current algorithm has many errors
in it cannot be easily simplified, if less than "all options"
are supported by a relying party.

3. The text states: "This algorithm assumes that all of the needed
CRLs are available in a local cache".

This sentence is incorrect, because it may happen that the "right"
or a "current" CRL is  unavailable and thus absent; in such a case
the algorithm terminates with "UNDETERMINED" or "UNKNOWN". 

4. The text states:

"This algorithm begins by assuming the certificate is not revoked."

This sentence is incorrect, the algorithm should begin by assuming
the status of the certificate is "UNDETERMINED" or "UNKNOWN".

5. The text states, [omitting what is relevant to delta CRLs]

"(a)  Update the local CRL cache by obtaining a complete CRL [ ] :

         (1)  If the current time is after the value of the CRL next
         update field, then do one of the following :

            (i) [ ].

            (ii)  Update the local CRL cache with a current complete
            CRL, verify that the current time is before the next update
            value in the new CRL, [ ]".

This is incorrect. If the "current" CRL cannot be found, then it is
still possible to use an older CRL to demonstrate that the certificate
was REVOKED. Of course, when using an older CRL it is not possible
to demonstrate that the certificate was NOT_REVOKED.

6. The current algorithm cannot make sure that an emergency CRL (
i.e. the latest captured CRL) will be used if more than one
"valid" CRLs are found in the local cache.

7. The text states:

   (f)  Obtain and validate the certification path for the complete CRL
   issuer.  If a key usage extension is present in the CRL issuer's
   certificate, verify that the cRLSign bit is set.

   (g)  Validate the signature on the complete CRL using the public key
   validated in step (f).

The text is unclear about what is meant by :" validate the certification
path for the complete CRL issuer". In order to solve the problem of
identical CRL Issuer names or identical CA names, it is needed to say
that the certification path that has been used to validate the target
certificate MUST also be used.

8. There is no handling of the Certificate Issuer CRL entry extension,
when present, which may lead to incorrect results.

9. The above list should not be considered as exhaustive.

This demonstrates the need to revise in depth section 6.3.

Denis

---

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

>   *target certificate* is REVOKED. So the sentence is incorrect.

The algorithm in section 6.3 is used to determine the status of a 
particular certificate, not a certification path, so the text is 
correct.  However, as part of certification path validation, section 
6.1.3, step (a)(3) states that, for each certificate in the path, one 
must verify that the certificate is not revoked or on hold, and it 
indicates that if status is determined using CRLs that section 6.3 
indicates how the status can be determined.

>   output is currently the revocation status of the certificate).

The variable cert_status is output from the algorithm.  In section 6.3.3 
steps (i) and (j), the value of cert_status is set to the value from the 
reason code CRL entry extension if the certificate is found to be 
revoked and the reason code extension is present.

> be functionally equivalent to the external behavior resulting

If you believe that this sentence and some of text quoted below need to 
be more precisely worded, please provide text for consideration.

> the algorithm terminates with "UNDETERMINED" or "UNKNOWN".

I don't understand what you mean by incorrect, the sentence states an 
assumption, not a fact.

> the status of the certificate is "UNDETERMINED" or "UNKNOWN".

cert_status is initialized to UNREVOKED.  If the status cannot be 
determined, cert_status gets changed to UNDETERMINED as the final step.

> to demonstrate that the certificate was NOT_REVOKED.

Section 6.3 states "Further, if the next update time of a CRL has 
passed, the algorithm assumes a mechanism to fetch a current CRL and 
place it in the local CRL cache."  So, while the scenario you describe 
could happen, section 6.3 states that the algorithm does not address 
this scenario.

> "valid" CRLs are found in the local cache.

True.  As long as untrusted mechanisms are used to distribute CRLs, the 
relying party cannot ensure that it has the latest CRL.

> certificate MUST also be used.

Would you like for step (f) to say that the validation should be 
performed as specified in section 6.1 and/or section 6.2?

Even though X.509 requires that names be unambiguous, there does seem to 
be consensus within the PKIX WG that 3280bis should impose some 
restrictions of the certification path used to validate a CRL in order 
to address the concern that a name collision might occur despite X.509's 
prohibition.  However, at the moment, WG consensus seems to be in favor 
of only requiring that the certification path for the CRL use the same 
trust anchor as the certification path for the corresponding CRL.  There 
is language about this in the security considerations section.  In order 
for 3280bis to be even more restrictive, it would need to be shown that 
there is WG consensus in favor of imposing such restrictions.

> when present, which may lead to incorrect results.

Section 6.3.3, steps (i) and (j) refer to section 5.3.4, which indicates 
how to process this extension.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Tue, 12 Jul 2005 08:53:03 +0200

David A. Cooper wrote:

> Even though X.509 requires that names be unambiguous, there does seem 
> to be consensus within the PKIX WG that 3280bis should impose some 
> to address the concern that a name collision might occur despite 
> X.509's prohibition.  However, at the moment, WG consensus seems to be 
> in favor of only requiring that the certification path for the CRL use 
> the same trust anchor as the certification path for the corresponding 
> CRL.  There is language about this in the security considerations 
> section.  In order for 3280bis to be even more restrictive, it would 
> need to be shown that there is WG consensus in favor of imposing such 
> restrictions.

I support more restrictions. If you wish to be able to use 
cross-certification to interoperate with other PKI and not  multiply the 
trust anchors used, "the same trust anchor" does not mean much 
constraint at all.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 12 Jul 2005 08:04:57 -0400

David Cooper,

At a minimum, the cogent paragraph in the security consideration section
should be enhanced to recommend use of name constraints when cross
certifying with a CA in another PKI.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jean-Marc Desperrier
Sent: Tuesday, July 12, 2005 2:53 AM
To: [email-masked]
Subject: Re: 3280bis: CRL validation: what is wrong and/or missing in
section 6.3

---

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

David,

See my responses below.

> indicates how the status can be determined. 

The sentence should be replaced with:

"This section describes the steps necessary to determine whether the
revocation status of a target certificate is revoked, not revoked or
unknown. If the revocation status is "revoked", the algorithm can
further indicate whether the certificate is on hold".

> The variable cert_status is output from the algorithm.  In section 
> 6.3.3 steps (i) and (j), the value of cert_status is set to the value 
> from the reason code CRL entry extension if the certificate is found 
> to be revoked and the reason code extension is present.

No.  Since (i) starts with "  (i)  If use-deltas is set" this is only
applicable with delta CRLs and not in the general case.

Without using delta CRLs it is important that the algorithm is able to
indicate the "on hold" status. Currently it does not.

> If you believe that this sentence and some of text quoted below need 
> to be more precisely worded, please provide text for consideration.

The response was/is indicated just below. We need different sections to
address the different cases. This is exactly was
<draft-pinkas-pkix-conf-crl-validation-01.doc> is trying to achieve.

> I don't understand what you mean by incorrect, the sentence states an 

The assumption is incorrect for several reasons :

   a) the needed CRL may not be available,

   b) there may be more than one valid CRL in the local cache:
      if so, the freshest is not necessarily selected,

   c) old CRLs may be used to determine that the certificate is revoked
      (of course, they can’t determine that the certificate is not
      revoked).

The current algorithm addresses none if the above three cases.
The I-D that I have posted addresses these three cases.
Please take a look at:
http://www.ietf.org/internet-drafts/draft-pinkas-pkix-conf-crl-validation-01.txt

> determined, cert_status gets changed to UNDETERMINED as the final step.

The text states :

    If the revocation status remains undetermined, then
    return the cert_status UNDETERMINED.

How can this been done, since there is no internal state that allows to
know that the revocation status is undetermined ?

It is much more practical to start the algorithm with the UNKNOW
cert_status which is the right status at the beginning of the algorithm,
since it allows to exit the algorithm at any time with the right status.

> could happen, section 6.3 states that the algorithm does not address 

  ... and this is why the assumptions currently made in 3280bis are
incorrect. As you say, 3280bis does not address this scenario but it should.

> True.  As long as untrusted mechanisms are used to distribute CRLs, 
> the relying party cannot ensure that it has the latest CRL.

You missed the point. If the latest CRL is in the cache, there is no
guarantee that it will even be seen. The I-D that I have posted
addresses this case.

> performed as specified in section 6.1 and/or section 6.2?

Certainly not ! The answer is just above. “THE FULL CERTIFICATION PATH
THAT HAS BEEN USED TO VALIDATE THE TARGET CERTIFICATE MUST ALSO BE USED
TO VALIDATE THE CRL ISSUER CERTIFICATE ”. This is the point that Stefan
supported in another recent e-mail. He was also thinking that it might
be possible that the CRL Issuer certificate could be issued by another
CA from the same certification path. However this would not work, since
this would not prevent name collisions.

> need to be shown that there is WG consensus in favor of imposing such 

It appears that your understanding of the consensus about naming in
X.509 is incorrect. Sharon has sent a very explicit message on the list
about this. We have to face the reality of possible name collisions
either accidental or voluntary. The same “trust anchor” does not solve
the issue, since it is insecure. A secure way to handle the issue is
mentioned above. Here it is again copied : “THE FULL CERTIFICATION PATH
THAT HAS BEEN USED TO VALIDATE THE TARGET CERTIFICATE MUST ALSO BE USED
TO VALIDATE THE CRL ISSUER CERTIFICATE ”.

> Section 6.3.3, steps (i) and (j) refer to section 5.3.4, which 
> indicates how to process this extension.

No. Section (i) starts with  “(i)  If use-deltas is set, …  “.
It is thus specific to delta-CRL and is not applicable in the general
case. Also there is no clear indication of the processing and referring
to section 5.3.4 is far from sufficient.

Denis