Subject: RE: OCSP in S/MIME and IPSEC

From: Khaja Ahmed <[email-masked]>
Date: Fri, 1 Sep 2000 17:21:05 -0400

Michael,

I was just unaware that this (signature with bundled OCSP response) was a
widely accepted (or at least well understood) "use case."   I was also
unaware that you and others had documented it elsewhere.  As someone else on
this thread pointed out the best way to formalize this is probably not in
the son-of-2560 but perhaps in signature format standards, in s/mime, etc.
I see the wisdom of that view and agree with it.

What you are calling "Asymmetric OCSP" is precisely what is needed in many
applications that I am aware of.  It has also been called "Freshness Proof"
in some applications.  "That which we call a rose by any other name..." etc.
By all means sign me up as a taker for this.  The only question that remains
is:  Where is this use best formalized and documented?  PKCS#7, PEM, S/MIME,
XMLDSIG or application that use these?  I do feel that it is important
enough and of sufficiently wide interest to warrant formalization in
standards.  I will be happy to support this effort in any way I can.

Khaja

-----Original Message-----
From: Michael Myers [mailto:[email-masked]]
Sent: Friday, September 01, 2000 12:51 PM
To: Khaja Ahmed; [email-masked]
Subject: OCSP in S/MIME and IPSEC

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: "Ray Langford" <[email-masked]>
Date: Mon, 4 Sep 2000 23:25:53 -0500

RE: OCSP in S/MIME and IPSECKhaja,

Hello. We also agree that bundling validation data (i.e. OCSP responses) with the signature can be beneficial (eg. for archival and later verification as you discussed). This capability has been in our Assured Transaction products for a while now. The storage of the validation data is managed via Assured Transaction Signature Policies. If you would like to see this "in action", I would invite you to download our latest Assured Office product (4.0, which is now in beta). Just send an email to [email-masked] to request the URL to the Assured Office beta website.

Also, a draft RFC was recently published <draft-ietf-smime-esformats-01.txt> as part of the S/MIME working group, which discusses bundling validation data with the signature. We are reviewing this draft and hope to help with this effort however we can.

Regards,

-- Ray

  ----- Original Message ----- 
  From: Khaja Ahmed 
  To: 'Michael Myers' ; [email-masked] 
  Sent: Friday, September 01, 2000 4:21 PM
  Subject: RE: OCSP in S/MIME and IPSEC

  Michael, 

  I was just unaware that this (signature with bundled OCSP response) was a widely accepted (or at least well understood) "use case."   I was also unaware that you and others had documented it elsewhere.  As someone else on this thread pointed out the best way to formalize this is probably not in the son-of-2560 but perhaps in signature format standards, in s/mime, etc.  I see the wisdom of that view and agree with it.

  What you are calling "Asymmetric OCSP" is precisely what is needed in many applications that I am aware of.  It has also been called "Freshness Proof" in some applications.  "That which we call a rose by any other name..." etc.  By all means sign me up as a taker for this.  The only question that remains is:  Where is this use best formalized and documented?  PKCS#7, PEM, S/MIME, XMLDSIG or application that use these?  I do feel that it is important enough and of sufficiently wide interest to warrant formalization in standards.  I will be happy to support this effort in any way I can.

  Khaja 

  -----Original Message----- 
  From: Michael Myers [mailto:[email-masked]] 
  Sent: Friday, September 01, 2000 12:51 PM 
  To: Khaja Ahmed; [email-masked] 
  Subject: OCSP in S/MIME and IPSEC 

  Khaja, 

  Takers, anyone? 

  Mike