Subject: Re: DPD/DPV Requirements

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

> 
> 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.

IMO there are independant requirements: 

- A method to enable response authentication by a third party
  or by the client. An example is a digital signature.

- Independantly of that the server can include an identity,
  and it is a matter of policy or local client(s) configuration
  about how this identification plays a role to authenticate
  a response.

If one needs more text than what Russ has proposed, then I'd say:

- A client SHOULD be able to indicate to the server in its
  request the identity or identities of server that it
  believe SHOULD contribute to the service. 

- A server MAY or may not honour these identifications.

- A server SHOULD be able to indicate in the response the
  identities of the servers that participated in providing
  the service.

- It is a matter of local configuration of a client to
  match a server identifier with a identifier associated
  to an authentication method, e.g., a signature. 

Peter

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 24 May 2002 17:22:02 +0200

Peter,

>   about how this identification plays a role to authenticate

A digital signature by itself does not allow to authenticate a client,
unless you can reliably know the public key to be used to verify the digital
signature. Since we are writing this specification for an open environment,
including the identifier of a DPV certificate provides such a reliable link.
This is what meant the previous sentence: "The DPV server's certificate MUST
authenticate the DPV server".

Denis