Subject: CRL Distribution Points

From: Russ Housley <[email-masked]>
Date: Tue, 26 Oct 1999 11:57:54 -0500

In reviewing the document that Tim recently posted, I realized that we were 
not really clear about the semantics of a DistributionPoint with an absent 
distributionPoint, a present reasons, and a present cRLIssuer.  The ASN.1 
is repeated below for those who have not memorized it.

If the cRLDistributionPoints extension does not contain a 
DistributionPointName, but does contain a cRLIssuer, then following 
semantics MUST be assumed:

1) If the cRLIssuer is of type directoryName, then the 
certificateRevocationList attribute in the Directory entry of the cRLIssuer 
contains the current CRL for the associated reasons.

2) If the cRLIssuer is of type URI, then the URI is a pointer to the 
current CRL for the associated reasons.  The expected values for the URI 
are those defined in 4.2.1.7.

3) Processing rules for other values are not defined by this specification.

Does this seem right?

Russ

= = = = = = = = = =

    CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint

    DistributionPoint ::= SEQUENCE {
         distributionPoint       [0]     DistributionPointName OPTIONAL,
         reasons                 [1]     ReasonFlags OPTIONAL,
         cRLIssuer               [2]     GeneralNames OPTIONAL }

    DistributionPointName ::= CHOICE {
         fullName                [0]     GeneralNames,
         nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }

    ReasonFlags ::= BIT STRING {
         unused                  (0),
         keyCompromise           (1),
         cACompromise            (2),
         affiliationChanged      (3),
         superseded              (4),
         cessationOfOperation    (5),
         certificateHold         (6) }

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 26 Oct 1999 19:39:00 -0400

Russ:

Please Annex M on X.509 Draft Amendment.  It will be a good idea to include
Annex M, point to it or borrow the applicable sections in the PKIX RFC.

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Tuesday, October 26, 1999 12:58 PM
To: [email-masked]
Subject: CRL Distribution Points

Does this seem right?

Russ

= = = = = = = = = =

---

From: Peter Williams <[email-masked]>
Date: Tue, 26 Oct 1999 17:01:44 -0700

Russ,

You need to ensure that an indirect issuer of the
CRL fragment can be identified, so that the signature
can be appropriately verified, as per the X.509 model.

How would we do that with your standard today? - whilst
also pointing to the location of the value in 
a directory/uri-resolver?

> From: Santosh Chokhani [mailto:[email-masked]]
> Sent: Tuesday, October 26, 1999 4:39 PM
> To: 'Russ Housley'; [email-masked]
> Subject: RE: CRL Distribution Points
> 
> 
> Russ:
>

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 26 Oct 1999 20:11:47 -0400

Peter:

The issuer of the CRL should be identified from issuer name field in the CRL
and not based on what directory entry or what attribute you queried.  The
directory is not trusted, the network is not trusted, and there is no strong
binding between the attribute value and the object/attribute.

-----Original Message-----
From: Peter Williams [mailto:[email-masked]]
Sent: Tuesday, October 26, 1999 8:02 PM
To: Santosh Chokhani; 'Russ Housley'; [email-masked]
Subject: RE: CRL Distribution Points

Russ,

---

From: Peter Williams <[email-masked]>
Date: Tue, 26 Oct 1999 17:35:25 -0700

> binding between the attribute value and the object/attribute.

But, from the standard(12.6.2	Certificate extension fields)
at ftp://ftp.bull.com/pub/OSIdirectory/ITU/97x509final.doc

"The cRLIssuer component identifies the authority that issues and signs the
CRL. If this component is absent, the CRL issuer name defaults to the
certificate issuer name."

I assume we are going to comply with X.509 concerning
the rules for identifying the issuer of a CRL, as given
above.  If not, the security section of son-of-2459 should
identify that PKIX validation processing is non-conforming with
the ISO standard.  
 
Peter.

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 27 Oct 1999 11:15:58 -0400

Peter:

My interpretation of the statement is that the issuer name in the
certificate should match the issuer name in the CRL.

-----Original Message-----
From: Peter Williams [mailto:[email-masked]]
Sent: Tuesday, October 26, 1999 8:35 PM
To: Santosh Chokhani; Peter Williams; 'Russ Housley'; [email-masked]
Subject: RE: CRL Distribution Points

 
Peter.

---

From: Peter Williams <[email-masked]>
Date: Wed, 27 Oct 1999 11:15:33 -0700

> Sent: Wednesday, October 27, 1999 8:16 AM
> To: 'Peter Williams'; Santosh Chokhani; 'Russ Housley';
> [email-masked]

This interpretation interferes with the X.509 specification which
enables use of ANY independently-named (validation) authority.  The 
CrIssuer field signals the identity  and intended use of a given 
authority  to relying parties, when optionally present. If the
cRLIssuer value is not present, the default rule you mention 
above controls. Otherwise "the issuer name in the
**cRLIssuer** value should match the issuer name in the CRL."

Let us also note that the name of the CRLDP, when the
RDN flavour is used, is subordinate to the **CRL issuer**,
as identififed using the CrlIssuer Rule, if one
is performing conforming processing. The cRLIssuer
is identified using the processing summarized above.

Why cannot we do the simple thing, and just implement
what X.509 specifies? Its hardly contentious, its
not hard,  and has already been ratified by the ISO voting 
process, which included a PKIX voice.

Lets now advocate the case, with famous-name examples to
make the case easier to follow:

Case
----

Folk have quite widely adopted the separation of power idea
between CAs and VAs (or those who indirectly
issug CRLs). Enterprises WANT to be able to
issue a local/extranet CRL, that controls whether a VeriSign
public certificate is flagged suspended in that
relying-party domain.

Taking IBM as the example enterprise customer that chooses
to quite normally outsource its ceritifcate manufacturing to
VeriSign, IBM may well wish to have VeriSign indicate
the users of IBM certificates should use a given , non-VeriSign
CRL issuer, identified in the CrlIssuer name using
an DN selected in the IBM corporate DN-name space. 

Policies for issuing IBM's indirect CRL would meet IBM 
guidelines, which may be more stringent than the those used by
VeriSign. Furthermore, for IBM is likely to have 
a significantly more realtime data at its RAs concerning
revocation/suspension data than VeriSign has, or has yet 
accepted for processing under its own CPS rules.  

Whether IBM or an outsource VA operate the IBM
CrlIssuer is an operational choice, much like
any decision to deploy a product server on
the IBM LAN, or use a service provider.

Conclusion, to date:
-------------------

The model argued above is what the cRLIssuer field
was designed for; processing must comply for a
user cert validation result to be conforming with X.509,
and for the allied process of confirming a certificate chain
to be similarly conforming.

I have no particular objection, if it is
technically appropriate, for PKIX to overload the CrlIssuer
signal with Russ' meanings

But one cannot simple replace
the original processing requirements with an
interpretative wave of the PKIX magic wand, and 
still be able to interwork securely with 
correctly-implemented X.509 certificate-using 
systems now widespread.

Peter.

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 27 Oct 1999 14:18:03 -0400

Peter:

You really need to carefully review the Annex M in the draft.  That should
explain it all.  If you find incompleteness, errors or inconsistencies in
that Annex, please let me know.  We would be interested in making that Annex
as complete and accurate as possible.

-----Original Message-----
From: Peter Williams [mailto:[email-masked]]
Sent: Wednesday, October 27, 1999 2:16 PM
To: Santosh Chokhani; 'Russ Housley'; [email-masked]
Subject: RE: CRL Distribution Points

Case
----

Conclusion, to date:
-------------------

Peter.

---

From: Peter Williams <[email-masked]>
Date: Wed, 27 Oct 1999 12:22:48 -0700

ftp://ftp.bull.com/pub/OSIdirectory/documentsForBallot/CertExtFPDAM.doc

At your suggestion I have reviewed the above-identified
amendment text.

For those who only want the bottom line of this mail, here it is:

	I suggest that a simple statement is added to that which 
	Russ has already 	drafted: it should state that 
	"X.509 processing of the crlIssuer field is REQUIRED, if
	present".

Annex M review, for the purpose or understanding Russ' request
for comment in light of Annex M:

I note, that wherever CA was formally, used,
the more general term "authority" is now substituted.
Authority is defined as CA or AA.

I note that the concepts of CrlDistribution Point
have not changed by amendment from the 
X.509 version used by 2459.

I do note that the whole concept of DPs has
been extended to the PMI, which is not part
of 2459 work. I ignored everything in 13.14
as out of review scope, for now.

Annex M1.1 states the CRL types, and helps
out the new scope idea, which is not part
of this review.

Annex M.2 specifies a logical procedure for
selecting CRL processing, based on CRL reliance
policy, defined in the CP.

Annex M.3 states the rules for selecting a CRL
from the various flavors available, according to 
various  requirements. The annex makes it
clear that 1 or more of the several DPs provided can 
be used when DP processing is appropriate.

The concept of dominance and freshness, nicely allows
the IBM override of VeriSign that I described,
whether or not cRLIssuer processing is used.

M.5.1.4 addresses one interaction of cert-based DP
signals and CRL-hosted DP signals. 

The first bullet points out a alternative matching rule 
covering DPName, or the optional CrlIssuer name. Either match is acceptable.

The last bullet states the crlIssuer rule I stated originally.

Annex M is very nice piece of work, which makes it easier
to do what the market requires.

Annex M is completely consistent with my argument, and
does not change the way X.509 has handled cRLIssuer
and indirect CRL signals.

Russ should ensure that his overloading of semantics
on the cRLissuer field continue require that the
base X.509 rules are followed, as stated in X.509
and even more forcefully stated in Annex M.5.1.4
of the FPDAM.
 
Is that a fair review and conclusion, tuned to the question 
posed?

The review only reinforced my original conclusion. Let
me know if I have made an error in my reasoning, or 
if there are other factors in play.  I just do
not want PKIX to be non-conforming with X.509.

I suggest that a simple statement is added to that which 
Russ has already 	drafted: it should state that 
"X.509 processing of the crlIssuer field is REQUIRED, if
present".

Thanks for insisting we all review Annex M. Persistence
in leadership does pay dividends.

Peter.

that indirect issuance is the same as used in the 

> Sent: Wednesday, October 27, 1999 11:18 AM

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 27 Oct 1999 17:16:00 -0400

I interpret RFC 2459, Section 5  to mean that the relying parties may
encounter ARL, DP CRL, and delta CRL.  Given that, the entire text of Annex
is pertinent to 2459, not just the check for indirect CRL issuer.  This can
be done either by reference or by inclusion.

-----Original Message-----
From: Peter Williams [mailto:[email-masked]]
Sent: Wednesday, October 27, 1999 3:23 PM
To: Santosh Chokhani; 'Russ Housley'; [email-masked]
Subject: RE: CRL Distribution Points

 

Peter.