Subject: RE: Usage of CRL Issuing Distribution Point

From: Trevor Freeman <[email-masked]>
Date: Tue, 16 Feb 1999 15:52:56 -0800

As with a lot of threads on the list, there have been some
miss-interpretations based on some terms having different meaning to
different people. Let me return to the original point.
It is important for the client to understand whether it is dealing with a
monolithic CRL or multiple CRL's. In the former case once it finds a current
CRL signed by the CA, it knows it is sufficient. Here the AKI extension is a
useful hint, but the signature check is conclusive proof the client has
found the right CRL. In the latter case there will be multiple CRL's all of
which current, and signed by the same CA. In these instances it is dangerous
for the CA to assume the reliability of the CRL distribution mechanism, and
therefore there is a need to include unambiguous information in the
Certificate AND CRL to inform the client if the CRL is partitioned, or not
where are these CRL(s) and it needs to know  from the CRL when it has found
them. Our in other words finding a object signed by the right authority at
the end of a URL or in a directory is not enough. 

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Tuesday, February 16, 1999 7:46 AM
To: Trevor Freeman
Cc: [email-masked]'
Subject: RE: Usage of CRL Issuing Distribution Point

Trevor,

I am puzzled by your statements. It is true that CRLs have some facilities
to explicitly mark which classes of certs may be contrained in them, e.g.,
only CA certs or only some revocation reason codes.  However, there is no
prohibition
against round robin assignment of certs to different CRLs through the use
of the CRL distribution point extension.  In fact, that would seem to be a
major feature of this extension.  Perhaps you are raising the question of
how one ought to note, in the CRL itself, that only a subset of certs
(e.g., partiitioned by serial number) are contained in a given CRL.

Steve

---

From: "Ambarish Malpani" <[email-masked]>
Date: Tue, 16 Feb 1999 18:14:18 -0800

Hi Trevor,
    If you look at the original description of how I said a
client should process a CRL/CRLDP, it actually covered the
issue you were talking about. To quote:

-----BEGIN QUOTE-----
P.S. To figure out which CRLs apply to the certificate you are
trying to check, you normally look for the path to the CRLs in
the certificate. Once you retrieve the CRL, you need to check
that the CRL has the same name as the one you thought you
were retrieving. So the extension you look for in the cert
is the one with OID id-ce-cRLDistributionPoints, while the name
of the CRL can be found in the CRL (if present), with the
OID id-ce-issuingDistributionPoint.
-----END QUOTE-----

Hope this clarifies the issue.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect					         650.567.5457
ValiCert, Inc.				        [email-masked]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833

> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of Trevor Freeman
> Sent: Tuesday, February 16, 1999 3:53 PM
> To: 'Stephen Kent'
> Cc: [email-masked]'

---

From: Stephen Kent <[email-masked]>
Date: Fri, 19 Feb 1999 09:55:37 -0500

Trevor,

Yes, this message thread certainly does seem to have become confused.
Hopefully we now agree that inclusion of a CDP extension in a cert allows a
relying party to determine whether it has the right CRL for the cert in
question, subject to the usual CRL validation processes.  Note that, in
this case, the relying party does not care whether there are multiple CRLs
or not, since the the CDP extension provided the necessary pointer.

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 22 Feb 1999 11:07:17 +0100

Steve,

You said " Hopefully we now agree that inclusion of a CDP extension in a cert
..". Not quite.

This technique only allows one case of partitioning where it can be said: for
this certificate, go there. Other schemes are not supported..

However there is a much more important concern. If we go this way we are going
to overload the content of *every* certificate. The same would apply to get
information about OCSP responders. If we are going to store certificates in
smart cards this is going to be a problem.

We should look for another solution able to solve this concern. Placing all
this administrative information in a *single* and new data structure signed by
the CA would need to be explored.

Opinions ?

Denis

---

From: Stephen Kent <[email-masked]>
Date: Mon, 22 Feb 1999 17:42:45 -0500

Denis,

>the CA would need to be explored.
I'm not saying we coulkd not envision other approaches, but we have one
solution now, it is in our standard, and thus it is an answer to the
questions we were discussing. New approaches to this problem may be
entertained in the future, but fopr now let's get on with what we have.

Steve