Subject: Re: DPD/DPV Requirements

From: Peter Sylvester <[email-masked]>
Date: Fri, 24 May 2002 11:23:58 +0200 (MET DST)

- It would be nice if the 'smart' apostrophes could be avoided.
 
- The text does not include a requirement that a server should
  be able to indicate in the response its identity. 
  This is symmetric to the requirement to allow an identity
  for the client (and the rationale is similar).

  I thought this was clear in the example: 

"We, the President of Unites States, and the General Secretary of
 the United Nation", certify to you, President of France, President
 of the French General assembly, and president of the French Senate,
 the the certificate XXYZ can be used by you as a strong authentication 
 method to demand deployment of a combined UN ad US forces on May 5 
 according to plan LEF". 

> 
> 
> Folks,
> 
> I haven't seen any comments on the latest draft of the DPD/DPV 
> requirements.  I view this as a sign that consensus has been reached, or at 
> least very near.  If I don't see any comments to the contrary, I plan on 
> forwarding the document to the Area Directors Tuesday morning.
> 
> Thanks,
> 
> Tim Polk
>

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 24 May 2002 09:51:38 -0400

>- It would be nice if the 'smart' apostrophes could be avoided.

Thanks for point this out, it is easy to fix.

>  method to demand deployment of a combined UN ad US forces on May 5

The paragraphs in question say:

   For the client to be confident that the certificate validation was
   handled by the expected DPV server, the DPV response MUST be
   authenticated, unless an error is reported (such as a badly formatted
   request or unknown validation policy).

   For the client to be able prove to a third party that trusts the
   same DPV server that the certificate validation was handled correctly,
   the DPV response MUST be digitally signed, unless an error is reported.
   The DPV server's certificate MUST authenticate the DPV server.

   The DPV server MAY require client authentication, therefore, the DPV
   request MUST be able to be authenticated.

   When the DPV request is authenticated, the client SHOULD be able to
   include a client identifier in the request for the DPV server to copy
   into the response. Mechanisms for matching this identifier with the
   authenticated identity depends on local DPV server conditions and/or
   the validation policy. The DPV server MAY choose to blindly copy the
   identifier, omit the identifier, or return an error response.

I suggest that we add the following sentence to the end of the 2nd 
paragraph above:

   The DPV server SHOULD be able to include a server identifier in the 
response.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 24 May 2002 16:50:52 +0200

Peter and Russ,

>    The DPV server SHOULD be able to include a server identifier in the

It is not clear to me in this additional sentence what a "server identifier"
would be. Given that the previous sentence says:

I would rather change the whole paragraph into:

    For the client to be able prove to a third party that trusts the
    same DPV server that the certificate validation was handled correctly,
    the DPV response MUST be digitally signed and include a DPV certificate 
    identifier, unless an error is reported.

Denis