Subject: RE: A few comments re: dpv-dpd requirements

From: "Trevor Freeman" <[email-masked]>
Date: Fri, 12 Apr 2002 12:31:43 -0700

Hi Mike,
I don't see how supporting an unknown response helps. Unknown sounds
like a sub-status on the failure case. If I did have multiple SA with
multiple DPV servers, anything other than a cert is valid response will
cause me to go select the next DPV server and try again. If I only have
one DPV server, then again, if it is not valid - it's invalid.
Insufficient information to be able to be able to complete the request
could be a sub-status reason returned in the DPV response, which allows
me to audit or account for why the cert was not used, but the DPV server
should only return one of two states.

Trevor

-----Original Message-----
From: Michael Myers [mailto:[email-masked]] 
Sent: Thursday, April 04, 2002 4:51 PM
To: [email-masked]
Subject: A few comments re: dpv-dpd requirements

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: "Michael Myers" <[email-masked]>
Date: Mon, 15 Apr 2002 13:18:42 -0700

Trevor,

Looking at this from an abstract state machine perspective I see
a first, binary branching.  Upon receipt of a query, you have
either:

1. FAILURE:  Something's wrong here, can't proceed, raise an
exception, send back an unsigned response; or

2. PROCEED:  Understand the query, send to the backend for the
heavy lifting needed to produce a signed response.

My model is basically a frontend/backend architecture that
protects the backend (and, in the case of DPV, its signing key)
from DOS attacks, among other Internet-facing nastiness.

This model assume of course that when a query gets to the
trusted backend, a signature is required.  While we're not
lawyers here, it's arguable that a trusted entity's digitally
signed assertion that a certificate is "invalid" could be
significant in a dispute when in point of fact that trusted
backend couldn't arrive at conclusion due to lack of relevant
data.

Given that we're still into the early stages of defining and
using these things, I think it's better we enable a digitally
signed "unknown" to cover this instance.

Mike

Michael Myers
t: +415.819.1362
e: mailto:[email-masked]
w: http://www.traceroutesecurity.com

> From: Trevor Freeman [mailto:[email-masked]]
> Sent: Friday, April 12, 2002 12:32 PM
> To: Michael Myers; [email-masked]
> Subject: RE: A few comments re: dpv-dpd requirements
>
>
> Hi Mike,