Subject: RE: Offline Root CA with valid CRL hierachie

From: [email-masked]
Date: Tue, 31 Dec 2002 16:23:01 -0700

note that this is one of the places that it would become difficult to turn
the current manufactored certificate infrastructure for SSL domain name
certificates into a PKI.

The customer of a SSL domain name CA are all the web servers in the world.
The relying-parties are (at least) every browser in the world (aka every
client in the world potentially having multiple browsers). "Every time"
would in effect be everytime a SSL/HTTPS session anywhere in the world was
ever initiated .... aka everytime a browser initiated an SSL/HTTPS session
there potentially would require a CRL fetch (assuming a pull paradigm;
assuming a push paradigm then every CA would have to transmit their CRLs to
every possible browser in the world .... with every possible client in the
world possibly having multiple different browsers).

Also .... there is some difficulty in a CA "telling" every RP in such an
infrastructure anything .... since actual RPs are infrequently
predetermined. Possible sidestep is some sort of browser intialization
informating the "human" operator of the browser some text extracted from
each pre-installed root certificate.

random ref:
http://www.garlic.com/~lynn/subtopic.html#sslcerts

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

[email-masked] on 12/31/2002 2:52 pm wrote:

Hi Mitchell,
    As a CA, you can tell the RP (relying party) that it is
responsible for fetching the latest CRL. If you then give it
no way of knowing when to get a new CRL, any serious security
client would keep checking for a new CRL *every* time it needed
to validate a certificate/certification path.

As a root CA, it is very unlikely that your directory could handle
the load you would get from every client trying to get your latest
CRL for every certificate that chains up to you (*distribution* is
the real scalability problem with CRLs - as opposed to OCSP - not
generation).

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [email-masked]
http://www.malpani.biz

---

From: [email-masked]
Date: Tue, 31 Dec 2002 16:22:38 -0700

random ref:

Hi Mitchell,

Regards,
Ambarish

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 31 Dec 2002 18:00:44 -0800

I don't get where this argument is headed...

There is no point in pre-generating CRLs. If you are only going to yank
the key out of the vault once every quarter you should tell people that
by setting your expiry appropriately.

CRLs really don't work if you want the ability to fine tune the update
quanta to respond to events. The best you will ever do is to have a
system where you can't stop a system relying on stale data.

CRL distribution is a problem, thats one reason we did OCSP, we needed a
way to make a compact validation blob that was not encumbered with
patents. But we can run OCSP as fast as the DNS so don't worry about the
scaling issue. If server signing turns out to be an issue we can
introduce a key exchange, most applications don't need non-repudiation.

		Phill