Subject: Re: Processing CRLs without Issuing Distribution Points

From: Russ Housley <[email-masked]>
Date: Tue, 15 Feb 2000 15:21:49 -0500

Sean:

The CRL reasons extension determines whether the CRL covers all of the 
certificates or not.  The handling of reasons turns out to be fairly 
complex.  Tim Polk and I spent quite a bit of time at a white board working 
out the details.  The CRL processing section in the soon-to-be-posted 
son-of-rfc2459 will hopefully address this.

Tim:

When ca we expect to see the next Internet-Draft?

Russ

At 11:21 AM 10/15/1999 -0400, Sean Mullan wrote:

>RFC 2459 does not require that CRLs contain an Issuing
>Distribution Point extension.
>
>Does this mean that a CA may issue *partial* CRLs without
>including an Issuing Distribution Point Extension?
>
>If the answer is yes, it is not possible for a relying party to
>safely determine if a certificate has not been revoked by inspecting
>a CRL without an Issuing Distribution Point extension. It cannot
>assume that a single CRL is an exhaustive list and it also cannot
>assume a sequence of CRLs when taken as one is an exhaustive list.
>Therefore a relying party cannot safely determine that the certificate in
>question has not been revoked.
>
>RFC 2587 (LDAP v2 schema) states that CAs may choose to store partial
>CRLs containing revoked CA certs only in the authorityRevocationList
>attribute, but makes no mention as to whether or not those CRLs should
>contain an Issuing Distribution Point extension. We claim they must in
>order for a relying party to be sure that the CRL is a partial CRL
>containing an exhaustive list of revoked CA certs only.
>
>Have there been any partial CRLs deployed w/o Issuing Distribution
>Point extensions?
>
>We think that RFC 2459 should be changed (or made more clear) to make
>the Issuing Distribution Point extension mandatory for CAs which split CRLs
>according to reason codes or user/CA type, and that relying parties
>should treat CRLs without an Issuing Distribution Point
>extension as complete (exhaustive) CRLs.
>
>--
>Sean Mullan                     Email: [email-masked]
>Sun Microsystems Laboratories   Tel:   (781) 442-0926
>One Network Drive               Fax:   (781) 442-1692
>Burlington, MA 01803-0902

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 15 Feb 2000 16:09:39 -0500

Russ:

The Annex in X.509 is written with the orientation towards how to validate a
certificate with respect to not being revoked.

That is what you want, I think.

In terms of specifics in the example below, your analysis and conclusions
are correct (as usual).

What the X.509 Annex does is define what other CRLs you may use to validate
the scope of reason code of interest to the application for give cert (A or
B) in your example.

Thus, the title of X.509 Annex is slightly misleading, but its focus is to
determine the validity of a certificate with respect to the revocation
information.  The annex does it in a modular fashion.  Any suggestions in
terms of its accuracy or presentation will be greatly appreciated by me and
the X.509 editor.

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Tuesday, February 15, 2000 3:59 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Processing CRLs without Issuing Distribution Points

Santosh:

We tried to mate the CRL validation section with the Certificate validation 
section.  We found that it needed to be revised for our purposes.  Also, 
the reasons was not clear (at least to Tim and I).

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}

A certificate user that tries to validate Cert-A should consider the 
intersection of the reasons from the DRLDP and the IDP when processing 
CRL-X.  Thus, processing CRL-X only covers keyCompromise.

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

Russ

At 03:24 PM 02/15/2000 -0500, Santosh Chokhani wrote:
>Russ:
>
>Do you think PKIX needs to go beyond the Annex developed for X.509, which
>now is the normative text?
>
>In other words, why can PKIX not adopt the X.509 CRL processing rules text
>or an abridged version of it?
>
>-----Original Message-----
>From: Russ Housley [mailto:[email-masked]]
>Sent: Tuesday, February 15, 2000 3:22 PM
>To: Sean Mullan; [email-masked]
>Cc: [email-masked]
>Subject: Re: Processing CRLs without Issuing Distribution Points
>
>
>Sean:
>