RE: DPD & DPV requirements

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

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:kent@xxxxxxx]
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