Subject: Re: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt

From: Peter Sylvester <[email-masked]>
Date: Wed, 31 Oct 2001 13:14:10 +0100 (MET)

> 
> Probably an application would only want one type of answer 
> consistently, but I suspect that someone could think up a situation 
> where one application would want different types of answers at 
> different times.

The question would be: Why is a DVP client in position to make
such a decision? 

> 
> >  > >You text described three options for DPV ?
> >>  >
> >>  >- please tell yes or no.
> >>  >- please only return THE path used for validation without telling
> >>  >   whether it is good;
> >>  >- both of the previous ones?
> >>
> >>  Correct. You might want both so you can act immediately on a yes but
> >                           ????
> >>  store the chain for later use, such as if you are online now but you
> >>  know you won't be later.
> >>
> >
> >Are you sure that you have THREE options, in particular does one
> >really need the second one, asking for a path without saying whether
> >it is good or not?
> 
> Yes, we want each one. The yes/no answer must be signed, which takes 
> non-trivial system resources on the part of the server. The path does 
> not need to be signed. The third option (both yes/no and path) is 
> still valuable for the reason I gave.
Why does a yes/no answer need to be signed? The DPV client
only needs to be able to authenticate the response in whatever way in
some cases.

'signed responses' is an optional requirement, this is only one means to 
determine the authenticity of a response which may allow reverification
even after the connection. I would formulate two requirements: 

- the authenticity of a response should be verifiable on receipt
- the authenticity of a response should be verifiable later on (eventually
  by someone eles than the requestor)

Why does 'the path not need to be signed' in DPV? 
I don't understand You statement for a DPV (attention not DPD) concerning 
a path not being signed, not authenticable. This seems contrary to what
DPV is doing. The DPV client does not perform path validation.  

What did I misunderstand here? 

I could imagine 4 different types of a DPV request parameterisation (policy).

  show always path.
  never show path.
  show path if answer is no.
  show path if answer is yes.

Regards

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 31 Oct 2001 11:41:40 -0500

>The question would be: Why is a DVP client in position to make

No, this is not the question.  I visualize two types of application using 
DPV.  The first type wants a yes/no response, and after validating the 
signature on the response will take an action immediately.  There is no 
need to record the reason, so the whole path is not needed in the 
response.  The second type of application wants to record the rationale for 
its action.  Such an application will want the whole path back.  The 
application designer will determine the application type.

Russ