[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: DPD & DPV Basics

Mike,

Steve,

Are we talking about the same thing?  Given a client-side initiation, it's
an OCSP request from an IPSEC GW/whatever to an OCSP server regarding that
incoming cert, then that GW/whatever turns around, gets *its* own OCSP
signed validation back from that same server (which public key the client
trusts) and drops it into the IPSEC handshake.

I guess we're not talking about the same thing.

I thought we were talking about a query to a DPV server by an IPsec client, where the DPV server then made use of an OCSP server. Thus I interpreted your comment as suggesting that the DPV server return not only an OCSP response, but also the cert for the OCSP responder. My observation is that if on choose to do this, why stop at the OCSP server cert, given that there is potentially much more context that might be required. For instance, do we assume that the OCSP server's cert has to fall under one of the trust anchors specified by the DPV client?

I would not have guessed, from the original message below, that the focus of your message was pushing OCSP responses in IKE.


Steve


<snip>

Mike

 > -----Original Message-----
 > From: Stephen Kent [mailto:kent@xxxxxxx]
 > Sent: Tuesday, January 16, 2001 7:41 PM
 > To: Michael Myers
 > Cc: PKIX List
 > Subject: RE: DPD & DPV Basics
 >
 >
 > Mike,
 >
 > >Carlin,
 > >
 > >It might also be useful to extend this concept the "asymmetric
 > OCSP" case,
 > >where a client's trusted server not only confirms the validity of the
 > >client's certificate via an external trust server but acquires from that
 > >same server an assertion of the validity of its (the protocol server's)
 > >certificate.  This response could be included in-band to the
 > client and so
 > >relieve the client of any further interaction with infrastructure to
 > >establish the server's trustworthiness.  IPSEC's protocol
 > architecture seems
 > >well suited to this design.
 >
 > One could imagine doing this, but when do we stop providing such
 > info? Do we provide a cert path and revocation status data for the
 > OCSP responder too?
 >
 > Maybe one should include the OCSP server's cert in an NR package, but
 > for a DPV server, I think it would not  be appropriate to pass back
 > this info discretely.
 >
 > Steve
 >
 >