RE: DPD & DPV requirements

["Slone, Skip" <skip.slone@xxxxxxxx>]

Steve,

Thanks for your response.  You've raised some good points that have caused
me to reflect a little deeper on how this subject would play out. In my
reflection, I reread the requirements message that prompted all this
discussion. The question now in my mind is whether we should take another
look at the differences between the DPV and DPD services. As of this moment
in time, it seems to me that perhaps we should consider the two to be
distinctly different animals, and that we should modify the requirements
document accordingly. I know this is bordering on radical, so I ask you to
bear with me for a few minutes while I explain my thinking...

Specifically, if we consider a DPV server to be nothing more than a special
case of a DPD client, we can keep the DPV client/server protocol extremely
simple. At the same time, we can allow the DPD client/server protocol to
represent the complex, signed, nested data structures necessary to convey
the various scenarios discussed on this thread over the last several days.
This separation also provides the restrictions necessary to accommodate the
concerns expressed regarding concepts like transitive trust.

If we go down this path of cleanly separating DPV and DPD services, a DPV
client could request service using an extremely simple query.  For example,
(other than the PDU headers) the query could contain as little as a
certificate, and the result could be as simple as a boolean. The client
might also express something like a required policy along with the
certificate, but a default scenario would allow this part to be omitted,
catering to highly constrained and/or "PKI-ignorant clients" (to quote you
and Denis). Alternatively, the response might express a slightly more
complex thought like "valid under policy X." The DPV server would be a
highly capable PKI-aware entity, responsible for obtaining the primitive
elements (certs and certificate validity status information) from whatever
sources are available, and for making a determination as to whether the
presented certificate is valid under some given policy at some given point
in time. The determination of validity could be determined, in part, by the
sources of the primitive elements.  For example, if a blob of certs and
status information is obtained within a signed structure, the validity of
the enclosing signature would be taken into account. 

By contrast, DPD would be a vehicle for gathering the primitive elements
needed to perform path validation, but would not necessarily make any
judgements on the validity of those elements. The DPD protocol would be
sufficiently flexible to allow the DPD client to express a variety of
starting elements (e.g., certs, CRLDPs, etc.) and/or path-related
constraints (name constraints, policy constraints, policy mapping
constraints, etc., as well as any new DPD-specific constraints). A service
control in the protocol could allow the specification of whether the client
requires complete paths in the response or if partial paths are acceptible.
The DPD server could be permitted to gather its data from any available
source (LDAP server, web server, FTP server, OCSP server, or DPD server), as
long as that source is consistent with the constraints specified by the DPD
client. The response PDU, which could (should?) itself be a signed
structure, can contain any primitive elements gathered by this DPD server,
as well as any nested, signed structures that resolve to primitive elements
at some arbitrary, yet pragmatically constrained level of depth.  I know it
sounds complicated, but I suspect a fairly straightforward, recursive data
structure could be specified to convey such a PDU.

In the scenario I previously described, companies A and B would provide DPD
services at their boundaries.  The RP inside company A would request either
DPV or DPD services from a company A server. That server would then request
DPD services from company B's server. The path validation elements would be
collected at company A (either at the DPV server or the RP itself) where the
determination of validity would take place.  In this scenario, there is no
need for DPV recursion, but DPV or DPD servers are permitted to act as DPD
clients as necessary. Path validation itself takes place at one point, using
all the essential elements gathered, and based in part on validating the
signatures on DPD responses from non-controlled sources.

Note that actual implementations could provide a combined DPV/DPD service
without implementing the more complex DPD protocol by keeping the DPV/DPD
interface internal to the system.

Is this too radical a departure from the previously articulated
requirements?

 -- Skip


-----Original Message-----
From: Stephen Kent [mailto:kent@xxxxxxx]
Sent: Friday, January 12, 2001 12:27 PM
To: Slone, Skip
Cc: PKIX-List
Subject: RE: DPD & DPV requirements


Skip,

Thanks for taking the time to supply an example scenario.  Your text 
was very readable and quite clear.

><snip>

>Putting the two sides of this equation together and looking at a typical
B2B
>scenario, we find the following case in which a relying party in Company A
>needs to validate a Company B path: the RP delegates its request to the DPV
>server residing on Company A's boundary.  Company A's DPV server (since it
>doesn't have direct access to Company B's network) will delegate to the DPV
>server residing on Company B's boundary.  Company B's DPV server will then
>access the internal resources in Company B's network, perform all the
>necessary discovery and validation work and return the result back
upstream.

I agree that the RP in Company A would call the DPV server that 
Company A makes available to it and that that DPV server needs to 
contact a server at Company B to get the necessary info. However, I 
don't agree that the DPV server at Company A would accept a DPV 
response from Company B, at least not blindly. Company B really needs 
to evaluate the response. It could do that by accessing a DPD server 
at Company B, or it could access a DPV server, but insist on getting 
back the data that supports the validation assertion by the Company B 
DPV server. If so, then what is returned by the DPV server will 
contain the same path and revocation status data as an equivalently 
formulated DPD response. So, I can see a case for offering only a DPV 
service to the outside world, but I might well choose to not accept 
just a yes/no response, if I were running a DPV server at another 
company. If that's the case, and if have to validate the returned 
data, then I could repackage it for return to my client (the RP), and 
the fact that there was a call to another DPV server is invisible to 
the client.

>As for the need to constrain the number of relays (on further reflection,
>"relay" seems like a better fit than "recursion"), consider the following.
>In the scenario above, there is a need to relay the delegation exactly one
>time. Thus, the RP inside A needs to allow a one-hop relay, but it may wish
>to preclude paths longer than that, in order to prevent getting to Company
B
>by first going through Companies X, Y, and Z.  On the other hand, it may be
>appropriate for a third party to be involved in the relay (industry
>consortium, bridge, TTP, etc.), which would make it appropriate to be able
>to specify two hops (or some other number as the situation warrants).

In your example, with clients inside of a corporate environment, it 
seems more likely that it would be a corporate policy that addresses 
the hop count issue, rather than a client parameter. also, I have to 
admit that I have a very strong bias here: transitive trust is 
generally a bad idea. It's OK for a client to rely on a DPV server in 
a corporate environment, and under some circumstances in a public 
environment. However, I'm very concerned about encouraging these 
servers to rely on other DPV servers, vs. DPD servers. And I'm 
especially concerned about the complexity that arises if such 
reliance becomes visible to clients, e.g, in terms of nested response 
syntax. I don't think the TTP or bridge CA example is a good analogy 
here, since any DPV server can do it's own validation on data 
returned by a DPD server for any other domain.

Steve