Subject: Certificate verification algorithm

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 14 Mar 2000 17:14:16 +0300

Hi,

I have one question about certficate verification algorithm described in 
son-of-2459. Section 6.3.3, Step1, second "b", (ii) on page 71 states:

---------------------------------------------------------------------
            (ii) If CRL X did not include an issuing distribution point
            extension, or the onlySomeReasons field was not present in
            that extension, set approved_reasons to "all_reasons."  If
            CRL X includes an issuing distribution point extension, and
            the onlySomeReasons field is present, assign
            approved_reasons the intersection of approved reasons and
                                 ^^^^^^^^^^^^
            the onlySomeReasons field.
---------------------------------------------------------------------

Isn't it a typo in this paragraph? Shouldn't it be "union" instead of 
"intersection"? Otherwise this logic is unclear to me.

The same paragraph appears also on the next page (72).

Regards,
Valera Smyslov.

---

From: Russ Housley <[email-masked]>
Date: Wed, 15 Mar 2000 13:56:13 -0500

Valera:

The text is correct.

I made a posting to this list while we were developing this text that 
explain is significant detail.  Let me see if I can try again.

Consider the following example:
    Cert-A contains a CRLDP that points to CRL-X with reasons
         {keyCompromise, affiliationChanged}
    Cert-B contains a CRLDP that points to CRL-X with reasons
         {cACompromise, cessationOfOperation}
    CRL-X contains an IDP with onlySomeReasons
         {keyCompromise, cACompromise, superseded}

The issuer of Cert-A is delegating the revocation notification of 
keyCompromise and affiliationChanged reasons to the issuer of CRL-X.  The 
issuer of CRL-X has not covered all of the reasons that the issuer of 
Cert-A expected.  That is, the affiliationChanged is not handled.  The 
intersection operation ensures that the validation of Cert-A only considers 
CRL-X for keyCompromise.

Similarly, a certificate user that tries to validate Cert-B, when 
processing CRL-X, only gets coverage for cACompromise.

Russ

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 16 Mar 2000 12:29:11 +0300

On 15 Mar 00, at 13:56, Russ Housley wrote:

Russ,

thanks for your reply. I understand your example. However, it seems to me that 
the current text doesn't follow the logic you've described. Let me try to 
explain it in more detail.

The "CRL validation" algorithm, described in 6.3, defines approved_reasons as 
the variable that "contains the set of revocation reasons supported by the 
approved_CRLs". It is initialized to the empty set. Then, each of the possible 
CRLs after its validation is processed as follows (until "the approved_reasons 
= "all reasons" or approved_reasons is a superset of which_reasons or 
possible_CRLs is exhausted"): if current CRL does'nt include an IDP extension, 
or the onlySomeReasons field is not present in that extension, set 
approved_reasons to "all_reasons" (special case); if current CRL  includes an 
IDP extension, and the onlySomeReasons field is present, "assign 
approved_reasons the intersection of approved reasons and the onlySomeReasons 
field".

In other words, apart from the special case when CRL doesn't contain IDP 
extension or that extension doesn't contain onlySomeReasons field, the text 
assumes that:

approved_reasons = approved_reasons AND IDP.onlySomeReasons

Even from the pure logic this is a senseless operation, because intersection of 
an empty set (initial value for approved_reasons) with any set will always be 
an empty set. From the logical point of view it seems to me that this should 
be:

approved_reasons = approved_reasons OR IDP.onlySomeReasons

e.g. approved_reasons should accumulate reasons that are covered by already 
processed CRLs until all reasons of interest are covered, so that we can skip 
the unnecessary processing of remaining CRL. Am I right?

However, after considering your example, it seems to me that correct logic 
should be:

approved_reasons = approved_reasons OR (CDP.reasons AND IDP.onlySomeReasons)

In other words, set of reasons, supported by current CRL must be considered as 
an intersection of the CRL's IDP.onlySomeReason field and the "reasons" field 
of the CDP extension that points to that CRL in the certificate being 
validated. Is it right? If so, this requires some modification to the 
algorithm, because  currently CDP.reasons doesn't take part in CRL validation 
algorithm at all.

Please, correct me if I'm wrong.

Regards,
Valera.

---

From: Russ Housley <[email-masked]>
Date: Sun, 19 Mar 2000 11:33:41 -0500

Valera:

You are correct.  I misunderstood your first posting.

We need to update the approved_reasons to be the union of the previous 
approved_reasons and intersection of the Certificate CRLDP reasons with the 
CRL IDP onlySomeReasons.

Russ