Subject: RE: DPD & DPV requirements

From: "Slone, Skip" <[email-masked]>
Date: Tue, 16 Jan 2001 14:38:55 -0500

Steve,

Judging from your response, I think I did both of us a disservice by
providing too many details from my stream of consciousness.  Here's the
distilled essence of what I intended to say:

In your requirements document you wrote, "Finally, this analysis suggests
that there are relatively few differences between a DPD and a DPV server ...
[T]he WG must decide if two distinct protocol formats, with different syntax
are warranted, or if a single [one] is appropriate."  You then went on to
conclude that they were sufficiently similar to justify a single set of
requirements.   

Based on the way the discussions have gone, I'm questioning this conclusion.
By separating the two, DPV could focus on simplicity and efficiency (to
better serve highly constrained clients), while DPD focuses on completeness
(to serve the needs of highly capable, but perhaps contextually constrained
clients). DPV could consume DPD services, creating a complete solution to a
wide range of problems.  

It is this last paragraph that I'd like comment on. Without some sense of
agreement at this conceptual level, it's fruitless to dig into details.

 -- Skip

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

Skip,

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

I think you have already lost me. Maybe this is because I have not 
seen strong arguments that result in the need for recursive call 
support, but I'l read on  ...

>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 must specify validation parameters, either directly or via 
reference to a policy, so no, the query cannot be as simple as you 
suggest.

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

PKI-ignorant clients are candidates for using the reference approach 
to specifying the validation parameters.

>Alternatively, the response might express a slightly more
>complex thought like "valid under policy X."

I think this is the minimum, simple query, and even here we need a 
strong reference to the policy, e.g., a hash to go along with the URL.

>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 "some policy" must be well defined, by the client.

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

You're loosing me again. Is the suggestion that receipt of a signed 
blob of certs from some source relieves the DPV server from needing 
to verify these certs? One could imagine that, if we allow recursive 
calls among DPV servers, but this makes for a more complex system and 
syntax, and I'd want to see good arguments about the benefits before 
we head down that path.

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

If a DPD server returns junk as an acceptable response I don't think 
that's especially useful, and it makes verification of "correct 
operation" either very hard or trivial :-).

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

Yes, it sounds complicated, and it is not clear what problem we're 
solving by allow this complexity. The proposed requirement for a DPD 
server is a simple one to understand, i.e., the server performs the 
function of collecting a complete cert path and associated revocation 
status data controlled by the same set of parameters that the client 
will use to validate the path. That means that the answer returned to 
a client will be useful for verifying the target cert, which is the 
goal for the client in the first place. You don't include details to 
motivate what the client does with the potentially piecemeal data 
returned by a DPD server as suggested above. I think you need to 
provide that, not just the high level scenario that initiated this 
threat, if we are to consider this alternative.

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

of course.

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

Well, it's not the radical part that bothers me; it's the lack of 
explicit, detailed motivation. The scenario you described can be 
satisfied by the previous proposal for DPD and DPV services, so the 
challenge is to articulate why creating a more complex interface to a 
DPD server, but allowing it to return possible junk, is desirable. I 
just don't see the point, yet.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 16 Jan 2001 21:04:13 -0500

Skip,

>agreement at this conceptual level, it's fruitless to dig into details.

I think we are seeing some divergence in arguments for the two types 
of servers, wrt queries and responses. They may be small enough to 
use a unified format with options, or we may have two distinct 
formats with a lot of overlap.  I'm not wedded to either approach. 
But, the need for both severs to perform path validation still seems 
to be true.

Steve