Subject: DPD & DPV Basics

From: Steve Hanna <[email-masked]>
Date: Thu, 11 Jan 2001 15:33:55 -0500

It seems that at least some members of the working group have not yet
agreed upon certain basic concepts. Perhaps it would be useful for me to
articulate these concepts so that they can be discussed separately from
the detailed requirements supplied by Steve. Discussion of those
detailed requirements can proceed simultaneously, but it would be good
if we could reach agreement on these basic concepts or at least
understand why we don't agree on them. I suspect that we already have
rough consensus on these concepts, but it would be good to get any
debate on them out into the open so that we can understand the technical
foundations from which that debate arises.

Here's my take on the basic concepts of DPD and DPV:

The basic job of a DPV server is to validate a certification path. In
its most basic form, it will perform the following steps:

1) Receive a request containing a certification path and other inputs
   to the validation algorithm (trust anchors, required certificate
   policies, etc.)
2) Validate the supplied certification path using the supplied inputs
3) Send a response containing the results of the validation (at least,
   an indication of success or failure)

Many refinements to this are possible: the client supplying only a
subset of the necessary inputs (by referring to an established policy),
the server returning supporting evidence such as CRLs and OCSP
responses, the client supplying CRLs or OCSP responses that may be
useful to the server, etc. But I think it may be useful to reach
agreement on the basic model described above before discussing these
refinements (however worthy).

The basic job of a DPD server is to discover a certification path. In
its most basic form, it will perform the following steps:

1) Receive a request containing a target certificate and inputs to the
   validation algorithm (trust anchors, etc.)
2) Attempt to discover a certification path ending in the target
   certificate that will validate properly given the supplied inputs
3) Send a response containing the results of the discovery process
   (at least an indication of success or failure and, in the success
   case, the discovered certification path)

Most of the refinements listed above with respect to the DPV server can
also be applied to the DPD server. In addition, other refinements might
include having the client supply additional certificates that may be
useful to the server (such as certificates received with an S/MIME email
message).

I look forward to seeing a discussion on this topic. If no discussion
results, I suppose that I will conclude that there is general agreement
about these basic concepts. However, simple affirmative messages
agreeing with these basic concepts would be useful in judging rough
consensus.

Thanks,

Steve

P.S. Due to the short timeline, I will submit more detailed comments on
Steve's requirements soon.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Jan 2001 18:17:51 -0500

Steve,

>refinements (however worthy).

I think the "refinement" re completeness of input is a basic issue, 
not just a refinement.  Also, the control inputs (non-cert and 
non-revocation status data) for validation may be explicit or 
references. I think the strawman motivated the need for both forms of 
specification, based on client capabilities, and the desire for 
centralized control of validation in some environments.  Also, the 
need for the DPV server to return data that supports NR seems like an 
important feature, for some set of apps, though not all.

>agreeing with these basic concepts would be useful in judging rough

I agree with the basic notions here, as qualified above.

Steve

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 12 Jan 2001 10:08:46 -0800

Steve,

> On Thursday, January 11, 2001 12:34 PM you wrote:
>

The current DPD I-D also defines a fourth area of functionality.  It enables
a client to iteratively discover a path acceptable to the client in the case
where a given certificate may be subject to multiple valid paths.

Mike

---

From: Steve Hanna <[email-masked]>
Date: Fri, 12 Jan 2001 14:51:02 -0500

> where a given certificate may be subject to multiple valid paths.

I'd say that's a refinement on the basic form listed above. It's
interesting, though. As I read your I-D, the RetryReference (which I
think is what you're referring to) allows the client to say "try again,
I didn't like that path". If there are many possible paths (as there
would be in a mesh topology), this probably won't work well. It would be
more efficient for the client to say what it's looking for in a path.

What things do you think a client might be looking for that couldn't be
expressed in the parameters supplied to the DPD server? And why? If
there is a short list with good reasons for each, we could provide a
standard way for the client to request those. But we should probably
provide this mechanism to handle the cases we missed. Of course, the
client could just refer to a validation policy OID that the server and
client both understand. But this won't handle the case where the server
and client haven't agreed on such a policy. Or where the client's
requirement is variable (all certs must contain a custom extension whose
contents match the project name I'm working on, or some such).

-Steve

---

From: Steve Hanna <[email-masked]>
Date: Fri, 12 Jan 2001 16:31:50 -0500

> important feature, for some set of apps, though not all.

Several people seem to have interpreted "refinement" as "not required".
I didn't mean that. I just wanted to focus on the most basic function of
a DPV or DPD server to make sure we had agreement on what that is.

> I agree with the basic notions here, as qualified above.

Thanks for your prompt response.

-Steve

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 15 Jan 2001 15:24:59 +0100

Steve,

> The basic job of a DPV server is to validate a certification path. 

I disagree. The basic job of a DPV server is to say whether a given
certificate is valid according to some validation policy. The client may not
provide any certification path.

> In its most basic form, it will perform the following steps:
> 
> 1) Receive a request containing a certification path 

No. See above.

> and other inputs

Yes. 

> 2) Validate the supplied certification path using the supplied inputs

No. He will have to fetch information (certs and revocation data).

>    an indication of success or failure)

Yes, and as an option the data used for the assertion.
 
> subset of the necessary inputs (by referring to an established policy),

.. or no subset at all.

> responses, 

No. The server returning a blob. The fact that the blob contains certs,
CRLs, delta CRLs, OSCP or whatever, is not visible.

> the client supplying CRLs or OCSP responses that may be
 
> The basic job of a DPD server is to discover a certification path. 

No. The basic job of a DPD server is to help the PKI-aware client to perfom
the validation itself.
Certification paths or/and revocation information may be returned. More than
one certification path and one than one revocation information (e. g. both
CRLs and OCSP responses) may be returned.

> In its most basic form, it will perform the following steps:
> 

Yes.

>    certificate that will validate properly given the supplied inputs

One or more paths.

>    case, the discovered certification path)

Succes or failure of finding the requested elements (i.e. certification
paths or/and revocation information)

> also be applied to the DPD server. 

No. See above.

> In addition, other refinements might

Yes.

> agreeing with these basic concepts would be useful in judging rough

Sorry, my message is going in the reverse direction. :-(

Regards,

Denis