[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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