Subject: Re: Huge CRLs

From: [email-masked]
Date: Fri, 10 Sep 1999 10:29:55 EDT

Good point!
But...
CRLs in any form are a fundamentally inadequate approach to solving practical 
problems and in most cases cannot meet business requirements for even small 
scale infrastructures.  CRLs were a good idea when the terribly impractical 
people who developed them were working on paper and not such a great idea 
when you have to turn paper into production systems.   CA revocations 
experiments done on practical deployments (real world machines, apps, and 
users) of even small PKIs will demonstrate that complying with your own 
policy won't happen in the real world if you base your revocation hopes on 
CRLS.
Why are you messing with them?

...kawika daguio...

---

From: Stephen Kent <[email-masked]>
Date: Fri, 10 Sep 1999 11:03:06 -0400

I think your message would be better received if you cited specific
technical reasons for criticizing CRLs, rather than the broad statements
you made dispoaraging them and the authors of X.509.

For example, I might be tempted to say that one should never pay attention
to messages from folks who have AOL mailbox addresses, since they are
probably technical illiterates, but that would be an inappropriate and
unsubstantiated comment.

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 13 Sep 1999 06:44:37 -0400

>Why are you messing with them?
Try addressing REALTIME validation.  OCSP caching MIGHT work, but an IPsec
device has millisecs to validate; no time for network latency to retrieve info.

Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]

---

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Tue, 14 Sep 1999 10:22:35 -0400

> device has millisecs to validate; no time for network latency to

The conclusion might be valid but the argument cannot be.

Consider the performance characteristics of two configurations, in the
first we have an IPSEC firewall behind a cheap router box at the border
of the corporate network. the IPSEC firewall uses CRLs for revocation
information checking.

In the second configuration we have an IPSEC firewall in the same position
as the cheap router. Directly connected to the cheap router is an
OCSP server which communicates with some backend run by the CA by
some irrelevant mechanism.

I submit that if the first configuration is feasible then the second
cannot be infeasible for reasons of latency.

As I said earlier the OCSP/CRL thing is a question of balance and
appropriateness. A truck can move pretty much anything, but it is
more comfortable to ride in a passenger car. Even so it is possible
to bamboozle folk into driving a truck when a car would be better,
just give it wrap arround bumpers, big headlights and call it an
SUV.

If we want to talk about scale then we have to set the target at
a significant level - like a few billion. It is clear that CRTs
cannot scale at that level, consider the difficulty of replicating
an entire trust tree over muliple distributors in real time. With
CRTs you lose one delta in your synchronization and your trust
tree is irreconcilably corrupted.

I presented a very large scale example at RSA'99 employing aspects
of both OCSP and OCDP CRLs. Nobody argued then that it was infeasible
although there were questions as to why scalling to billions was
necessary.

The reason scalling to billions was necessary was to try to show
that this is an unnecessary argument. It is possible to scale revocation
technology to global scale WITHOUT using proprietary technology.

The significance of OCSP is this. It is not sensible, practical or
ecconomic to build a revocation infrastructure which addresses
the planetary scale PKI at present while the size of the largest
PKIs is in the small millions. OCSP permits a decoupling of the
revocation/validation problem from the client implementation. This
in turn means that when it is necessary and usefull to build
revocation/validation infrastructures with planetary scale the
legacy client (ie working, deployed client) issue is not going
to block progress.

		Phill

---

From: "Ambarish Malpani" <[email-masked]>
Date: Tue, 14 Sep 1999 14:44:06 -0700

Hi Bob,
    Not sure if you have already heard us talk about this, but we
have been talking about the "Freshness Seal" concept for a pretty
long time now, where, along with your certificate, you can send
along the proof that your certificate has not been revoked. At that
stage, the certificate recipient can verify the status of your
certificate without ever needing to make a network connection.

Also, you can amortize the Freshness Seal over all the connections
you make over a certain amount of time. Works very well for
server kind of applications. Also reduces the load when a busy
server is trying to serve a number of clients.

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

> -----Original Message-----
> From: Robert Moskowitz [mailto:[email-masked]]
> Sent: Monday, September 13, 1999 3:45 AM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: Huge CRLs
> 
>