Subject: Summary:open issues for draft-ietf-pkix-dpv-dpd-req-03.txt

From: Tim Polk <[email-masked]>
Date: Thu, 04 Apr 2002 18:01:06 -0500

Folks,

I think the discussion is converging here, and thought a summary was in
order.

There are a number of issues that were raised on the list and have
demonstrated consensus on the list.  (I will not enumerate
them.)  Proposed text has been submitted to the list and I sense
general satisfaction with that text.

However, there are two open issues that must be resolved before we
forward the document to the Area Directors.

Open Issue #1

The first issue involves "DPV relay".  Peter Sylvester
has stated a requirement for DPV servers to relay requests to one
another:

>There is a requirement, similar as for OCSP caches,

>that server just relays a request to another. This had been

>discussed several times, the differences had only been to

>what degree the relaying should become visible; whether one

>server can rewrite/resigns the answers of another etc.

>Relaying via cache is an obvious feature in many OCSP implementation,

>how do they protect itself against loops between two servers?

I understand this issue remains open.

Open Issue #2

The second issue is conformance requirements for multiple paths in
the DPD service.  As I read it, the current draft requires support
for multiple paths at the server, but not the client.  The client
may request a maximum number of paths N; if the request does not specify
N, it defaults to one.  The DPD server includes zero, one, or up to
N paths in a response.  If the number of paths is less than N, this
indicates that the server could not find as many paths as the client
requested.

Since the DPD process is performed with respect to a policy, just as in
DPV, it has been suggested that a DPD server could be designed to always
return a single path.  If the specified policy matches the path
validation process performed at the client (e.g., same certificate
policies and same trust anchor) the client should be able to use that
path.

However, this could result in an ambiguity.  How does the DPD client
that requested three paths tell the difference between the following
answers:

"I
gave you one path because it is the only one that exists"

and

"I
gave you one path 'cause that's the way I was designed"

In the case where the single path failed, a client may need to know the
difference!

Careful selection of conformance requirements and error condition
statements will be required to permit building single answer DPD
servers.

Moving Forward

Here is my plan for moving forward...

I will start two threads for the remaining open issues.  I consider
all other issues regarding the DPD/DPV requirements to be resolved.

Once the last two issues are resolved, I will ask the editors to post an
-04 draft incorporating the currently agreed changes and the resolution
to the two open issues.  The -04 draft will be forwarded to the
ADs.

Hope this works for everyone.

Thanks,

Tim Polk

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 4 Apr 2002 16:50:31 -0800

Russ, Denis:

The state "unknown" is missing in Section 4, "Delegated Path
Validation Protocol Requirements".  The -03 draft currently
reads:

"The DPV response MUST indicate one of the following two status
alternatives:

1) the certificate is valid according to the validation policy.
2) the certificate is not valid according to the validation
policy."

I think -04 should read:

"The DPV response MUST indicate one of the following three
status alternatives:

1) the certificate is valid according to the validation policy.
2) the certificate is not valid according to the validation
policy.
3) the certificate is unknown to the validation server."

Thus we remain at {valid, invalid, unknown} as primary initial
states per list-based consensus.  Apologies for digging into
this, but it has relevance to the design of state machines.

Mike

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 05 Apr 2002 12:37:45 +0200

Michael,

> 3) the certificate is unknown to the validation server."

I do not think you really mean this, but rather:

3) the validity of the certificate is unknown according to the 
   validation policy.

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 05 Apr 2002 15:02:16 +0200

Tim,

> demonstrated consensus on the list.  (I will not enumerate them.)
> Proposed text has been submitted to the list and I sense general
> satisfaction with that text.
> 
> However, there are two open issues that must be resolved before we forward
> the document to the Area Directors.

> The first issue involves "DPV relay".  Peter Sylvester has stated a
> requirement for DPV servers to relay requests to one another:

> I understand this issue remains open.

The proposed resolution to close this issue is the following:

  " In case a DPV server chooses to relay the request to another server 
  using the same protocol, a method to detect loops MUST be supported 
  by that relaying server."

> The second issue is conformance requirements for multiple paths in the DPD
> service.  As I read it, the current draft requires support for multiple
> paths at the server, but not the client.  The client may request a maximum
> number of paths N; if the request does not specify N, it defaults to one.
> The DPD server includes zero, one, or up to N paths in a response.  If the
> number of paths is less than N, this indicates that the server could not
> find as many paths as the client requested.
 
> DPV, 

Not exactly. A validation policy does not equate a path discovery policy. A
validation policy shall be set to return a path that meets all the criteria
from the requester since one and only path valid path is returned. A path
discovery policy may be much more simple and, for example, only specify one
trust anchor and say that all CRLs that may be found should be returned. So
in that case, many certification paths could be returned and the client will
locally apply additional criteria.

> it has been suggested that a DPD server could be designed to always
> return a single path.  

The suggestion has been made, but this does not work. See the argument
above.

> If the specified policy matches the path validation
> process performed at the client (e.g., same certificate policies and same
> trust anchor) the client should be able to use that path.
 
> However, this could result in an ambiguity.  How does the DPD client that
> requested three paths tell the difference between the following answers:
>         "I gave you one path because it is the only one that exists"
>      and
>         "I gave you one path 'cause that's the way I was designed"
> 

This problem would exist *if* the suggestion that a DPD server could be
designed to always return a single path was valid, but it is not. No change 
to the current wording of the document is needed.

I hope we can close this issue too.

Denis

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 5 Apr 2002 07:50:34 -0800

> -----Original Message-----
> > 

Denis,

That is fine.

Mike