In message <[EMAIL PROTECTED]> on Thu, 18 Sep 2003 16:04:28 +0200, "Mats Nilsson"
<[EMAIL PROTECTED]> said:
mats.nilsson> Sorry. Imprecise wording. I meant that since I would
mats.nilsson> like to be able to terminate the certificate validation
mats.nilsson> at a particular point in the certificate chain, it would
mats.nilsson> be pointless to verify CRLs beyond that point, wouldn't
mats.nilsson> it?
You mean that it's meaningless to go to the parent of the point of
trust? I agree with that, since your point of trust, at least when
expressed the way I showed earlier (having it's own root certificate),
is the root of your verification path.
mats.nilsson> But the default algorithm of OpenSSL-0.9.7b is to either
mats.nilsson> verify CRL for the leaf cert and nothing more, or to
mats.nilsson> verify CRL:s for the entire chain, which I'm not always
mats.nilsson> interested in. So I have overridden those methods.
Well, with my scheme, the "entire chain" goes from the leaf to your
point of trust, not further. Checking CRLs between those two points
makes sense, doesn't it? Henrik Nordström outlined the reasons to do
so in message <[EMAIL PROTECTED]>.
mats.nilsson> Furthermore, not all certificates are equipped with a
mats.nilsson> CDP extension field, why we have added the possibility
mats.nilsson> in our database to selectively indicate well-known CDP:s
mats.nilsson> at various levels in the chain. It was this aspect of
mats.nilsson> selectivity that crept into my statement.
The lack of CDPs is a burden, I agree. That doesn't make you avoid
CRLs, though, which is what I thought you said you were doing. Quite
the contrary, in fact...
mats.nilsson> The scheme you (Richard) just outlined, where a CA could
mats.nilsson> have multiple certificates, leads me to think that our
mats.nilsson> views are not that far apart after all, at least given
mats.nilsson> that we express ourselves carefully. The point of that
mats.nilsson> scheme is to allow different clients to select how far
mats.nilsson> down the certification path to go, isn't it? Same goal
mats.nilsson> as I have.
Exactly. Actually, it allows more interconnections between different
PKIs (which has both positive and negative implications, but that's a
different story). If you want to look information on this, I'd start
with searching for "cross certificates", cross certification" and
"mesh PKI". I can recommend the book "Planning for PKI" by Russ
Housley and Tim Polk (if you look at the start of RFC 3280, you'll
recognise at least one of them :-)).
Note that the kind of infrastrusture I'm refering to exists in only a
few places, and isn't quite used in your normal SSL/Certificate
managing. You're among the first I've noticed on this list that's
doing something that is inching in that direction...
--
Richard Levitte \ Tunnlandsvägen 3 \ [EMAIL PROTECTED]
[EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-8-26 52 47
\ SWEDEN \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
