Subject: Re: Huge CRLs

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 13 Sep 1999 12:53:31 -0600

Isn't this problem solved by the use of the CRLDistributionPoint mechanism?

Is thought IE5 was already checking CRLs, if the CRLDistributionPoint was 
specified?

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

DISCLAIMER:
  If this message (with or without attached documents) is digitally signed, and/or if certificates are attached, the intended purpose is to 
   (1) Ensure that e-mail came from the apparent sender
   (2) Protect e-mail from tampering
   (3) Ensure that the content of e-mail sent to me and encrypted in  my dual-use key cannot be viewed by others.
  It is explicitly NOT the intent of any such signed message or document to represent any type or form of legally binding contract or other representation, and any such interpretation should not be considered commercially reasonable and WILL BE REPUDIATED, notwithstanding any wording or implications to the opposite effect in the text of the message itself; due in part, but not exclusively, to the fact that the security of my workstation and its associated cryptography is not judged adequately strong for such purposes at present.

>>> Ed Gerck <[email-masked]> 09/13/99 05:33AM >>>

Ben Laurie wrote:

> Ed Gerck wrote:
> > Further, the major X.509 security application today, SSL, does not
> > check revocation lists -- so they are near to useless. Also, the user is
> > not able to check server certificates (and certificates in the CA chains)
> > against revocation lists.
>
> That depends on the implementation. It is entirely possible for an SSL
> implementation to check CRLs, and some do.

In SSL, the client knows which CAs are acceptable *to the server* for signature
validation and CRL verification because the server *sends* a list of distinguished
names in the "certificate request" message. However, there is no corresponding
list sent in the other direction in SSL (from the client to the server).  Thus,  the
server is essentially groping in the dark when trying to supply a certificate that
the client can check for its CRL, because the server is not informed by the client
what CAs to best aim for in a ranking list  (CAs that are directly trusted by the
client for signature and CRLs, untrusted CAs directly trusted by a CA that
the client trusts, etc.).

So,  SSL indeed does not offer a mechanism to allow clients to effectively check
CRLs for server certs.  Thus, as I commented, "the user is not able to check
*server certificates* (and certificates in the CA chains) against revocation lists"
-- BTW, as we can see in current browsers.

But, your remark does apply to client certs that are sent to the server and I am
thankful for your clarification.  The major use of SSL is however in securing
servers and in this case CRLs are oftentimes useless for clients.

BTW, my text was a segment from the paper "Overview of Certification Systems"
at http://www.mcg.org.br/certover.pdf -- and even though there the context of
users checking *server certificates* seems clear throughout, I will further clarify
it with your comment in mind.

Thanks,

Ed Gerck