Subject: Re: Huge CRLs

From: [email-masked]
Date: Tue, 14 Sep 1999 13:06:00 -0600

Aram,

I don't know how your mail package works, but what GroupWise does is allow me to do a "Hit the Road", which updates my laptop with copies of mail that is normally  stored on the server. I suppose either IMAP or POP3 could do the same thing.

In any case, I have a bunch of unread messages I want to work through on the plane, and I want to confirm their signatures.

It's true that I might not know that a certificate was revoked just after I got on the plane, but if I get a current CRL status at the time I hit the road, or even when I got the message, that is probably fresh enough for most of my purposes.

Ideally, I would like to be able to specify a "freshness" criteria that CRLs would have to meet, or at least have the date/time of the last CRL update provided.

But except in the case of nonrepudiation (Oh no, Captain Bill, not the black hole again! :-), I probably don't care all that much. And I'm certainly not going to delay taking action for another two weeks, just to see if someone's certificate shows up as revoked.

Remember, just because someone's certificate is revoked, especially for relatively innocuous reasons such as a change or name or address, that does NOT necessarily invalidate the signature, it just makes it somewhat harder to prove that reliance was reasonable.  And in most cases the signature is NOT the only type of evidence I have -- I could probably recognize a message from Ed Gerck, or Steve Kent, or lots of other people, whether they signed it or not.

If, and only if, there is a message of such overwhelming importance that I just absolutely have to know that it was valid, I would wait until I could reestablish a connection, and then ask for the latest CRL, delta CRL, or OCSP.

Presumably the CA doesn't queue up revoked certificates until the time of next update.  Next update time is provided in order to signal me that I have missed a CRL, but normally I would expect to get an up to date status every time I ask for a new CRL.

That's one of the reasons why I can't get very excited about OCSP -- it makes the server sign every response, whether or not there was a change from the previous one.

Bob

>>> "Aram Perez" <[email-masked]> 09/14/99 10:16AM >>>
Bob,

In either case you are stuck with the same problem: you don't know whether
the signer's certificate is valid until you get the next "certificate
status" update, whether you get the status via a CRL or OCSP.

BTW, if you weren't on-line, how did you get the signed e-mail? ;-)

Regards,
Aram Perez

> 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: "todd@gmtsw" <[email-masked]>
Date: Tue, 14 Sep 1999 14:35:32 -0700

Bob - can I play devil's advocate for a minute?

Isn't the issue of CRL-Use specific to the structure and form of the CPS
<--> CP<--> RPA relationships really? With this in mind, I have to ask the
question "isn't this totally about policy and its operation?"...

What I think is really going on here is that the structure and facility of
CRL use is specific to the operating model and nothing else, unless your
going to implement the control policy in the mechanical form of the protocol
itself (insert laughter here!).

Whether the aged CRL data is too old to be of use to you in your specific
application, is directly defined in the trust model specified in the CPS
<--> RPA agreements and nowhere else. The CP then wraps an operations policy
context around the bigger view to complete the picture.

Todd

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, September 14, 1999 12:06 PM
Subject: Re: Huge CRLs