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

From: Ambarish Malpani <[email-masked]>
Date: Tue, 30 Oct 2001 10:19:06 -0800

Denis, as you already know, I agree with Russ and Paul. I would
prefer to see DSV as a separate effort. I think it is likely
to detail the DPV-DPD effort significantly.

After DSV gets stable, we can revisit this decision and see if it
makes sense to pull it back into the DPV-DPD effort.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:[email-masked]]
> Sent: Tuesday, October 30, 2001 8:53 AM
> To: [email-masked]; [email-masked]
> Subject: Re: draft-ietf-pkix-dsv-dpv-dpd-req-00.txt
> 
> 
> 
> On reflection, I agree with Russ about the removal of the signature 
> policy material. It may be appropriate for this WG, but not in this 
> document. Recent history with this group shows that there is a wide 
> divergence of opinion about the requirements and applicability of 
> signature mechanisms.
> 
> At 7:41 PM +0000 10/25/01, Denis Pinkas wrote:
> >Validation of Digitally Signed Documents is required in the 
> context of a
> >non-repudiation service and requires either the use of 
> Time-stamp tokens or
> >of Time-marks.
> 
> Quite true. This is a good reason to move it to a separate document. 
> Many uses of PKI have nothing to do with digitally signed documents, 
> but instead simple things like authentication mechanisms.
> 
> >Validation of Public Key Certificates is fine for real-time 
> use only, but
> >not for non repudiation purposes, otherwise clients would 
> not be "thin" and
> >would have to do more processing.
> 
> Non-repudiation is important to only a subset of PKI users. Further, 
> it is not clear that if you specify the DSV requirements in a 
> different document that this will cause clients that use the eventual 
> protocol to be less "thin".
> 
> >Instead of removing this material, I believe that additional 
> explanations
> >should be given in the document.
> 
> I disagree. Adding additional explanation will drag out the 
> requirements process.
> 
> >>The client always wan the path and the related revocation 
> information
> >>returned, so it is not necessary to say why. It is primarly not for
> >>archiving purposes but for real time use. Nevertheless, if 
> you really want
> >>this to be mentioned, please make a proposal for an insertion.
> >
> >At 6:47 PM -0400 10/25/01, Housley, Russ wrote:
> >No, this was not my point.  In DPV, sometimes the client simply want 
> >a Yes/No.  Other times the client wants Yes/No and the supporting 
> >data.  The request should allow the client to say which should be 
> >returned.  Only sent the supporting info if the client wants it.
> 
> Russ is right: the client doesn't always want the supporting data. 
> Proposal for insertion at the end of the section:
> 
> The client may request that the server indicate a valid or not valid 
> response, that the server return the path of certificates used to 
> determine a valid response, or that the server return both.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
>