Subject: DPD/DPV Requirements

From: Tim Polk <[email-masked]>
Date: Thu, 23 May 2002 17:22:11 -0400

Folks,

I haven't seen any comments on the latest draft of the DPD/DPV 
requirements.  I view this as a sign that consensus has been reached, or at 
least very near.  If I don't see any comments to the contrary, I plan on 
forwarding the document to the Area Directors Tuesday morning.

Thanks,

Tim Polk

---

From: Brian Hunter <[email-masked]>
Date: Mon, 27 May 2002 14:32:42 +0200

I have a question regarding the valid/invalid/unknown status of a DPV
request.

In 4.1 it states that there are 4 possible status' that could be
returned.  Then 3 possible reasons for invalid are given:

"When the certificate is not valid according to the validation policy, 
then the reason MUST also be indicated. Invalidity reasons include:

   a) the DPV server cannot determine the validity of the certificate 
      because a certification path cannot be constructed.

   b) the DPV server successfully constructed a certification path, but
      it was not valid according to the validation algorithm in 
      [PKIX-1].

   c) ... "

The three example reasons seem to be a remnant from -03 when there were
only two states (valid/invalid).  Can someone tell me for what reason an
unknown status would be returned?  I am confused because I thought that
reason "a" would be for unknown and reason "b" would be for invalid.

Thanks for the clarification.
Brian

---

From: "Michael Myers" <[email-masked]>
Date: Mon, 27 May 2002 08:13:10 -0700

Brian,

The reason is, servers (responding parties) need a means to
escape out of making a definitive assertion to clients (relying
parties) in the event the server (responding party) knows
absolutely nothing about the certificate in question.

Mike

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Brian Hunter
> Sent: Monday, May 27, 2002 5:33 AM
> To: Tim Polk
> Cc: [email-masked]
> Subject: Re: DPD/DPV Requirements
>
>
>

---

From: Brian Hunter <[email-masked]>
Date: Mon, 27 May 2002 17:30:56 +0200

Mike,

Thanks.  But I would still assume that that would also mean a server
would want to say unknown if it could only partially build a path,
(reason "a" below), since "I cannot find the CA certificate of the
certificate in question (ie I know absolutely nothing about the
certificate)" is a subset of "I cannot build a path".

Brian

---

From: "Michael Myers" <[email-masked]>
Date: Mon, 27 May 2002 09:07:48 -0700

Brian,

This case is more a matter for the protocol design/selection
stage of what we're up to here.  I'm certain there'll be ample
opportunity for discussion and debate on this case and many
others once we get to that stage.  But for now, it's sufficient
that a high-level requirement exist for an "unknown" state as
defined.

That said though, an inability to build a policy-compliant path
is either an error or unknown but certainly not invalid. The
latter assertion clearly implies the server has built a path.

At present, I would lean towards this being an unsigned error
since the scenario you describe suggests the server at least
recognizes the subject certificate.  It could be the case that
the client specified a policy that requires the path to transit
a bridging CA of which the server is completely ignorant.  In
that particular sub-case, an unsigned error response of
"unsupportedPolicy" seems most appropriate.

Mike

> From: Brian Hunter [mailto:[email-masked]]
> Sent: Monday, May 27, 2002 8:31 AM
> To: Michael Myers
> Cc: [email-masked]
> Thanks.  But I would still assume that that would
> also mean a server would want to say unknown if
> it could only partially build a path,
> (reason "a" below), since "I cannot find the CA
> certificate of the certificate in question
> (ie I know absolutely nothing about the

---

From: Brian Hunter <[email-masked]>
Date: Tue, 28 May 2002 09:10:20 +0200

Mike,

Ok, then I will leave this topic for the protocol discussions.

Brian