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

[Petra Barzin <barzin@xxxxxxxxxx>]

Russ,

I agree with most of your comments - except the following:

"Housley, Russ" schrieb:

> In section 4, 1st paragraph, I think that we do trust the DPD server to
> return the most current information that is available.  Clearly, this is a
> radically different situation than a DPV server, but it is a security
> relevant point, especially if the DPD client does not have a good source of
> time.  In other words, the DPD client trusts the server to provide up to
> date data, not stale data.

Like Denis I see a DPD server as an untrusted server. A client doesn't need
to trust a DPD server because all information returned is integrity protected
and he can check the content, e.g. the validity period. The client needs to have
a good source of time! Otherwise he couldn't locally validate a certificate.
You must trust an DPD server as much as an LDAP server or an OCSP
responder. They are all untrusted servers, even so you have to trust the
administrator to always update the database in time.

> In section 5, 8th paragraph, I understand the reasons why a client might
> want to perform DPV based on some previous time T.  DPD for  some previous
> time T is another matter, and I do not think that repositories provide the
> information necessary to implement such a service.

I think the DPD protocol MUST provide the possibilty to request and return
cert pathes based on some previous time T. That's an important requirement.
You agree that an DPV request/response need to be based on a previous
time T. Well, if the client only delegates the path discovery but does the
validation locally he may need the certificates from a previous time T.
An implementation of a DPD server MAY not support it or the repositories
MAY not provide this information. In this case the DPD server simply
returns an error.

Petra