Subject: RE: DPD & DPV requirements

From: "Slone, Skip" <[email-masked]>
Date: Thu, 11 Jan 2001 12:38:44 -0500

Steve,

The scenario I'm envisioning would be easiest to describe with the aid of a
whiteboard, cocktail napkin, or similar medium.  But, alas, I'm restricted
to email at the moment, so I'll do the best I can to draw a good mental
picture...

What I'm envisioning is a typical scenario that companies will face in the
B2B space over the coming years.  Imagine a diagram with an Intranet cloud
on one each side, with those two clouds each connected, via a firewall, to
the Internet, which is drawn in the middle.  In that environment, any
traffic that goes from Intranet A to Intranet B must traverse two firewalls
to get to its destination.

Now, fast forward a few years and you'll see that what we now call firewalls
have morphed into full-fledged boundary service environments, complete with
inward and outward facing portals and a whole bunch of servers of various
sorts, servicing the needs of each enterprise at its respective boundary.
Glossing over a lot of details, I think it's reasonable to think that
DPV/DPD servers (mostly DPV) can play a huge role in this boundary service
environment.  

Looking at the in-bound side, it's reasonable to assume that in the presence
of this capability, some companies will choose to provide DPV servers at
their boundaries and to prohibit direct in-bound traversal of their
boundaries for path discovery/validation purposes. Further, it is reasonable
to assume that companies that err of the side of paranoia will only service
DPV requests coming from known (i.e., preconfigured) sources, such as DPV
servers on the boundaries of known trading partners.

On the out-bound side, many companies currently restrict direct out-bound
access to nearly anything, requiring proxies and similar relay services
instead. As we move forward, I see this kind of restriction likely to
increase.  Thus, relying parties inside a network who need to validate
external certificates may find very few paths available for the various
steps involved in path discovery and validation (most likely a combination
of not-so-basic-DNS, LDAP, HTTP, and FTP interactions). By making path
validation available on the boundary, companies will find an attractive
alternative.  Internal RPs will be able to simply delegate the task to a
boundary-resident DPV server.

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.

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

That's it for now... thanks for listening.

 -- Skip

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Wednesday, January 10, 2001 5:10 PM
To: Slone, Skip
Cc: PKIX-List
Subject: RE: DPD & DPV requirements

Skip,

If we do agree to support DPV server recursion, then the suggested 
changes are appropriate ones to consider.

First, though, on what basis would you propose that a client 
enable/disable recursion or set a depth limit? Since a client is 
completely dependent on a DPV server to answer a query, and has no 
local means of validating any supporting data sent along with the 
answer, what does recursion say about the trust that the client 
places in the server? If one believes that trust is transitive, 
recursion may well be fine, and a simple numerical limit on depth of 
recursion would not seem to be a good way to express limits on the 
transitivity (e.g., one bad choice of a DPV server for reliance is 
enough to kill you). If you don't think trust is transitive, then 
recursion is inappropriate, unless you operate in a closed 
environment where the recursion is among servers operated by the same 
org and is really just an internal decision on how to implement the 
server.

Perhaps this is one reason why I am not yet comfortable with adding 
recursion to servers. I'd like to see some analysis of why it makes 
sense, whether it makes sense for both DPD and DPV, etc.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 12 Jan 2001 12:26:34 -0500

Skip,

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

><snip>

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

>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