Subject: RE: some thoughts re DPD and DPV

From: Stephen Kent <[email-masked]>
Date: Tue, 3 Apr 2001 13:15:48 -0400

At 5:20 PM -0800 3/23/01, Michael Myers wrote:
>Steve,
>
>Speaking from the OCSP perspective, our formulations of OCSPv1 and OCSPv2
>implicitly assumed and continues to assume that policy management between
>relying parties and validating parties is out of scope.  We of the OCSP team
>agree that the parallel development of such protocols is strongly preferred
>vice deltas to OCSPv2.

There is no need for the policy registration/query mechanism to be 
part of the protocol that provides the base DPV/DPD service. My 
question was whether we progress both at the same time, or complete 
the DPD/DPV protocols first, then provide the policy management 
protocol.

>I have no problem with an optional evidentiary hash in a DPV response if
>it's client-precipitated.  As Denis and I had discussed earlier this week,
>some environments may prefer this to the constant reiteration by a server of
>a full chain or other policy indicators (e.g. the full text of a policy
>document).  We will take this as a requirement and study how best to fold
>this requirement into the current OCSPv2 technical framework.
>
>When you refer to "incremental queries relative to the same target
>certificate" are you speaking to the currently proposed retryReference
>mechanism?

yes.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 3 Apr 2001 13:44:21 -0400

At 2:26 PM -0700 3/24/01, Carlin Covey wrote:
>Paul and Steve,
>
>I agree that the DPD and DPV protocols should be simplified by
>including just a reference to a server-resident path-validation
>policy.  I also agree with Paul that a typical client will
>make a choice among very few policies.  In fact, most clients
>will never make a choice.  The clients and servers will be
>pre-configured with one policy per client-type per enterprise. 
>Simply including one policy OID in the request (possibly echoed
>in the response) will satisfy the great majority of use cases. 
>
>Paul points out the near-zero success-rate of policy protocols.
>DPD/DPV should not be made into a quasi-policy-protocol by
>including explicit policy information in the requests.  An OID
>will do.  If there remains a need for client-configuration of
>server-resident policies, put that in a separate protocol as
>Steve has suggested. 
>
>Let's proceed with a simplified, low-bandwidth DPD/DPV that is as
>free as possible of the burden of policy configuration.

I think this is what I was proposing.

Steve