Subject: RE: Open issue: DPV additional information

From: Peter Williams <[email-masked]>
Date: Thu, 25 Apr 2002 11:51:25 -0700

We are much closer, Denis. Thankyou for your thoughtful
message on the target issue.

Let me reformulate a description of the mode that our RP-grade customers
need of DPV, based on our having deployed SCVP and having 
got(ten) their feedback on needs and requirements. Lets see if we 
are now in agreement tht the model is embraced within the
DPV requirements document. Im looking for an assurance, from you, not 
adoption of my phrasing. If the model is unacceptable,
we need to fix the requirements.

A validation policy is a rule set, executed by a DPV server;
the policy document has no operational function, and makes no assertions:
a validation policy serves as configuration for a DPV server that performs
delegated path processing on behalf of the DPV client - who
is normally an RP. 

The DPV server operator may make (NR) assertions by issuing
a DPV response. For a given DPV request, the DPV server selects the 
validation policy from a set of policies, which the operator
has configured it to handle, based on the citation
of required policy by a DPV client. The selected validation policy
indirectly controls the NR assertions that the operator makes. 

If the user cites a validation policy to a DPV server,
and that validation policy rule identifies that a particular 
OCSP server is "locally trusted", then revocation 
information from that source may be used in 2459
path processing by the DPV server.

If a DPV user does not wish to use a validation
policy that names a particular OCSP responder as
locally trusted, it should not cite that validation
policy identification. Citation of a policy
by a user implies that a user is prepared to
accept the underlying validity of the assurance data 
supplied to the requestor by the DPV server alongside 
NR assertions, including such assurance
data as OCSP responses.

>>>>An "OCSP responder that is locally trusted by the DPV 
>>>>client through a
>>>>validation policy rule" does not make sense. An OCSP 
>>>>responder can be
>>>>trusted under a given validation policy. If an OCSP 
>>>>responder is locally
>>>>trusted by a client, then the DPV server is unaware of it.
>>>>
>>>>In the chain of trust: a validation policy does not know 
>>>>who the clients are
>>>>and it is a validation policy issuer that defines which 
>>>>OCSP responders are
>>>>trusted, not the clients. It is up to the clients to query 
>>>>DPV servers they
>>>>trust and then they will accept whatever is defined in the 
>>>>validation
>>>>policy.   
>>>>
>>>>Denis
>>>>
>>>>> and that the DPV server will accept the OCSP response on the
>>>>> client's behalf in a manner conforming to the rules of 
>>>>OCSP standard.
>>>> 
>>>>> Given every opportunity to confirm this entailment, todate, Denis
>>>>> has not done so. With confirmation, we can proceed.
>>>>

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 26 Apr 2002 12:19:00 +0200

Peter,

See my comments below.

> OCSP server is "locally trusted", then revocation

I would say: 

OCSP server is directly trusted under that policy, then revocation 

> policy identification. 

We are very close, but I would say it slightly differently.

Before using a validation policy, the user shall make sure that it fits its
needs. 

> policy identification. 

Most of the time a RP will be ignorant of the details of the validation
policy and thus will take it as a whole or not. Some managers may inspect a
policy to that level of details (e.g. look which OCSP responders are locally
trusted) and then tell RPs which policies are adequate or not.

> Citation of a policy

Yes.

Denis