Subject: RE: DPD & DPV: Strawman proposals - DPD signatures

From: "Manger, James H" <[email-masked]>
Date: Wed, 24 Jan 2001 18:35:06 +1100

Does DPD necessarily need to sign the result?
I thought a DPD server was more analogous to an LDAP directory - you don't
have to "trust" them (though you may rely on their collective availability).
D = Discovery

A DPD searches out all the required items (certs, CRLs, OCSP responses,
timestamps, ...), but each of those items has its own signature so the DPD
server itself does not have to be trusted (in the same sense that you don't
need to trust a directory that stores certificates).

[Note: this is in sharp contrast to DPV (V = validation), where there is
definite trust placed in the server so it must be authenticated as the
origin of the result.  Another reason for separate protocols.]

> ----------
> From: 	Denis Pinkas [mailto:[email-masked]] 
> Sent:	Tuesday, 23 January 2001 20:45
> To:	IETF-PXIX
> Subject:	Strawman proposals for DPV and DPD
> 
	...
> STRAWMAN PROPOSAL FOR DPD :
	..
> Mandatory output : A digital signature over all the outputs (including the
> input parameters as well) in order to provide authentication with
> integrity.
	...

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 24 Jan 2001 15:55:37 +0100 (MET)

> have to "trust" them (though you may rely on their collective availability).

Why not consider using an LDAP query for DPD,
i;e.,  and define either some additional control if necessary, or 
just the data that have to be put into this 'server', and the
queries that have to be send. 

This would work in some way with CRLs and certs. 
 
> origin of the result.  Another reason for separate protocols.]

If the DPV response is not intended to be stored by the client
together with some other data, but just to make a local decision,
then no signature is necessary, only server authentication, for
example by SSL/TLS. If the client application want to store the
result this is different.

It may be necessary that the response can be authenticated later
by another verifying entity, this mean that an appropriate
security envelope is necessary. A signature is one possible way.

----

How many people think that we are talking about two separate
protocols?

---

From: Stephen Kent <[email-masked]>
Date: Wed, 24 Jan 2001 10:39:53 -0500

>have to "trust" them (though you may rely on their collective availability).

Signing is not required, but some form of authentication and 
integrity checking should be employed to detect attacks on the 
communications between the client and server, e.g., as a 
countermeasure for more subtle DoS attacks.

>need to trust a directory that stores certificates).

Right.

>origin of the result.  Another reason for separate protocols.]

A signature is not needed for DPV in all cases either. Only if the 
client wants NR for the DPV response is it necessary. If the client 
is relying on the DPV server in a context that does not involve NR, 
then why would the client require a signed response, vs. an 
authenticated response?

A signature is one option for effecting integrity and authentication, 
as well as a basis for NR. I think it reasonable to require support 
for signatures for DPV responses, and to make them optional for DPD 
responses. If so, then we might find great similarity in the DPD and 
DPV response formats, at least in this regard.

Steve