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

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 30 Oct 2001 08:52:54 -0800

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