Subject: RE: Huge CRLs

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 14 Sep 1999 17:53:14 -0600

I agree with the feasibility of both cases, and we've been thinking 
about both.

But the tradeoff of having the server, vs. the client, do the cryptographic
validation is a very serious server performance issue,.

In addition, there are even worse issue of trust management. 
Do I, as the individual who is making the decision, necessarily
trust my server to make my decisions for me, whether that server 
is operated by my company, or by an independent ISP?

What if it is personal mail?

And clearly the server is not going to apply content-based transaction
rules -- about the best it can do is the syntactic validation in 
accordance with the PKIX rules. And I'm not certain I would trust 
it to enforce Policy OID constraints, etc.

But there is also third case, which is that the server somehow 
updates my cache of status information for everyone that is in 
my address book, together with the authoritative status for the 
current mail (i.e., the address book is updated).  

Don't bother sending me the CRL for everyone who ever moved after 
getting a certificate from VeriSign -- that's like sending me a high priority
message telling me that the corporate link to Pago Pago is going down --
I don't care.

I think that solution places the trust back where it belongs -- on 
the individual user's desktop, not far away from his eyeballs.

Is there a protocol that would do that conveniently, without requiring 
that my ISP become a trusted third party?

Bob

>>> "Ambarish Malpani" <[email-masked]> 09/14/99 03:41PM >>>
Bob, there are actually 2 ways I would address that:

1. Your mail server could do the validation and only send you
messages that were validated (assuming you trust your mail server
*and* your mail server has the same cert validation rules as you
do).

2. You could use the "Freshness Seal" method, where the sender of
the mail (or the mail server), gets the revocation status proof
and sends it to you with the message.

In either case, the proof is obtained by somebody who is online.
You get the proof when you go online to get the mail message. You
can digest the proof in the "luxury" of your plane seat!

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: Bob Jueneman [mailto:[email-masked]] 
> Sent: Tuesday, September 14, 1999 8:29 AM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked] 
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked] 
> Subject: Re: Huge CRLs
> 
> 
> On the other end of the time spectrum, try using OCSP, or any 
> other protocol other than CRLs, in disconnected mode while 
> you are on an airplane reading your signed e-mail.
> 
> Bob
> 
> >>> Robert Moskowitz <[email-masked]> 09/13/99 04:44AM >>>
> At 10:29 AM 9/10/1999 -0400, [email-masked] wrote:
> 
> >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?
> >
> 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: Wed, 15 Sep 1999 10:55:47 -0400

> current mail (i.e., the address book is updated).  

Two approaches Bob,

1) Make a significantly large OCSP request listing every certificate
that is likely to be used (the whole address book is likely to be
overkill). Cache the response.

2) Use OCDP to chop up the CRLs into reasonably small chunks. Develop
some retrieval mechanism (perhaps an OCSP variant).

Both approaches are equivalent in the limit of a very small CRL.

The case of recieiving email is simpler. The mail server should have
the ability to push the OCSP token or CRL partition down with the email.
[I somehow doubt that this is within the capability of sendmail's
macro language but so what, plenty of better mail servers exist.]

Note that there would be problems with this approach if the signed
message was enclosed in an encrypted email:-)

The key to this problem is to make the validation information compact 
enough. OCSP is therefore a very suitable solution. If we assume that
the mail client and server will be communicating over an encrypted
line (SSL or IPSEC) we can in any case expect a public key operation
to be involved.

	Phill