Subject: RE: OCSP in S/MIME and IPSEC

From: Peter Williams <[email-masked]>
Date: Fri, 01 Sep 2000 13:33:03 -0700

Policy management and roaming protocols
are already a core part of  products
like SecureRemote/Client from Checkpoint.

http://www.checkpoint.com/products/vpn1/secureclient.html

Plugging OCSP into the backend of the policy
server seems an obvious thing to do.

If that policy server was then transactionally-aware,
it could also offload some legal obligations from
the client when dealing with one or other CA in
the various trust networks. I think Mike is
re-validating the 4-corner model; wherein
reliance for a particular purpose is controlled by parties 
other than the  CA. CAs just do key and authentication management,
an increasing commodity available everywhere, even
comes for free with Windows. The network or such infrastructure 
as transaction/policy servers enforce the business 
and/or legal reliance logic.

-----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: Robert Moskowitz <[email-masked]>
Date: Fri, 01 Sep 2000 16:53:20 -0400

At 12:51 PM 9/1/2000 -0700, Michael Myers wrote:

>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
>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,
>LDAP etc. to fetch a CRL.  Also, there's no client-side state maintenance
>there's sufficient platform cycles and bandwidth to do this efficiently (vs.

ISAKMP can easily send info like this in the Main Mode payload.  I think it 
is the 4th packet.

But just as easily, the GW can send the CRL to the gateway.  And if the CA 
has partitioned its CRLs, all of the gateways could be in one CRL with the 
road warriors using a different CRL.  So the CRL in the GW can can be nice 
and small too.

Either way it would work well.  Anyone with a two-headed coin?

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

---

From: Khaja Ahmed <[email-masked]>
Date: Tue, 5 Sep 2000 03:16:44 -0400

Ray,

This has been most helpful.  Thanks much.  Are you, or is anyone else, aware
of efforts to add such validity proofs to PKCS#7 and xmldsig?

Khaja

-----Original Message-----
From: Ray Langford
To: Khaja Ahmed; 'Michael Myers'; [email-masked]
Sent: 9/5/00 12:25 AM
Subject: Re: OCSP in S/MIME and IPSEC

Khaja,
 
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] <mailto:[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  <mailto:[email-masked]> Ahmed 
To: 'Michael Myers' <mailto:[email-masked]>  ; [email-masked]
<mailto:[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]
<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 

-----Original Message----- 
From: Khaja Ahmed [ mailto:[email-masked]
<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

---

From: Michael Myers <[email-masked]>
Date: Tue, 5 Sep 2000 07:45:06 -0700

Khaja,

I wouldn't hold that including OCSP responses in S/MIME is "widely accepted"
at this point, nor "well understood", but it has been discussed.  Your
proposal into this forum simply raised the visibility of this option beyond
the current casual conversations.

Perhaps it's time to formalize the approach given the field experience to
date with OCSP.  I agree that it's best for other signature format groups
(including our peers in the S/MIME group) to consider this integration.  I'm
not as immediately familiar with CMS as I know others are on this list.

Perhaps Russ Housley, Jim Schaad, Dave Solo et. al. would care to chime in?

Regarding integration with IPSEC as proposed, perhaps someone leading in
Sara's IPSRA WG would equivalently offer themselves as a point of
convergence?

Mike

-----Original Message-----
From: Khaja Ahmed [mailto:[email-masked]]
Sent: Friday, September 01, 2000 2:21 PM
To: 'Michael Myers'; [email-masked]
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, 
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

-----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] 

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