Subject: OCSP in S/MIME and IPSEC

From: Michael Myers <[email-masked]>
Date: Fri, 1 Sep 2000 12:51:02 -0700

Khaja,

I heartily agree.  In fact, this was one of the leading "use cases" I cited
very early on for OCSP's utility.  I don't see though that this case
requires any amendment to OCSP.  Could you elaborate on why you think this
is so?

And as long as we're on the subject, I've been off-and-on talking to folks
about an operational concept I've been calling "Asymmetric OCSP."  (first
briefed publicly a couple of RSAs ago.)

The concept applies best to the road warrior using IPSEC to securely reach
back home, to a customer site on a trouble call, etc..  Basically, during
the IPSEC setup phase the IPSEC server or gateway first checks the RW's cert
by reference to an enterprise OCSP server.  There you get
revocation/validation enforcement on the client.  The server or gateway then
turns around and asks the OCSP server for status on it's (the gw's) cert,
puts this into the handshake and so delivers back to the client
revocation/validation assurance.

It's in-band and clean since the client doesn't have to collaterally run
LDAP etc. to fetch a CRL.  Also, there's no client-side state maintenance
re: CRLs.  The client gets realtime effects on the revocation of a gw's
cert.  Finally, all the heavy lifting is done in the back office where
there's sufficient platform cycles and bandwidth to do this efficiently (vs.
forcing a limited client to go fetch CRLs from wherever using whatever
protocol.)  

Takers, anyone?

Mike

-----Original Message-----
From: Khaja Ahmed [mailto:[email-masked]]
Sent: Thursday, August 31, 2000 4:27 PM
To: 'Karl Scheibelhofer'; Peter Sylvester; [email-masked];
[email-masked]
Subject: RE: RFC 2560 - OCSP - Clarification

Under some circumstances or for some communities it may be possible for the
sender of the signed data to send along with the signed data proof that at
the time of signing (+/- some tolerance limit) the certificate was not
revoked. In other words, the sender could get an ocsp response from a common
trusted responder and include this with the transmission of the signed data.
This approach offers the advantage that the response can be archived /
stored along with the signature.  At a later date when the archived / stored
signed data and signature is retrieved it can be readily verified as having
been valid at creation time (+/- tolerance limit).  
Is this not an ability that we should formalize and add to appropriate
protocols like OCSP? 
Khaja 
Phone: (+43) (316) 873-5540

---

From: [email-masked]
Date: Wed, 06 Sep 2000 14:47:55 +0100

Michael Myers writes ("Asymmetric OCSP"):

>The concept applies best to the road warrior using IPSEC to securely
>reach back home, to a customer site on a trouble call, etc..
>Basically, during the IPSEC setup phase the IPSEC server or gateway
>first checks the RW's cert by reference to an enterprise OCSP server.
>There you get revocation/validation enforcement on the client.  The
>server or gateway then turns around and asks the OCSP server for
>status on it's (the gw's) cert, puts this into the handshake and so
>delivers back to the client revocation/validation assurance.

Perhaps I'm missing something, but this appears to suggest that the
client is expected to accept the server's unexamined claim that its
own cert is unrevoked.

If the GW cert is being used to support the server's side of the IPSEC
connection, then there is definitely a problem.

David Boyce

[email-masked]

---

From: "sankar ramamoorthi" <[email-masked]>
Date: Wed, 6 Sep 2000 10:15:19 -0700

>To: [email-masked]; Michael Myers
>Cc: Khaja Ahmed; [email-masked]
>Subject: RE: Asymmetric OCSP (was: Re: OCSP in S/MIME and IPSEC)
>
>
>
>From: [email-masked]
>[mailto:[email-masked]]
>Sent: Wednesday, September 06, 2000 6:48 AM
>To: Michael Myers
>Cc: Khaja Ahmed; [email-masked]
>Subject: Asymmetric OCSP (was: Re: OCSP in S/MIME and IPSEC)
>
>

Since the CRL is a signed quantity it should not matter whether the
CRL comes from the server itself - right?

However a server may choose only to send the base CRL and not
the delta CRL information and thus may hide the truth that its certificate
is
revoked. How should this scenario be handled by the client?

>[email-masked]

-- sankar --

---

From: Marc Branchaud <[email-masked]>
Date: Wed, 06 Sep 2000 19:59:53 -0700

This idea is very useful, but it's important to keep in mind that it isn't
applicable in all situations.

In particular, it breaks down when the client and the server/gateway don't
trust the same entities.  The server/gateway may be able to get an OCSP
server to sign off on its certificate, but that's useless unless the client
somehow trusts that OCSP server.

So while embedding OCSP responses works fine for road-warriors and similar
situations, where both parties belong to the same trust domain (so to speak),
it doesn't work when a client from one domain wishes to authenticate a server
in another domain.

I don't mean for this to be a show-stopper or anything, but I do think any
specification of such a system has to be clear about where things break down.

		M.

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

---

From: "todd glassey" <[email-masked]>
Date: Thu, 7 Sep 2000 12:11:37 -0700

Doesn't it seem like a AD and the associated use model descriptions would
displace most all of this argument. What is going on here is the there a
number of orthogonal uses in people heads and since there is no one place to
point to and say - this is what it is and this is how its supposed to be
used in the real world... well what can I say.

Todd