Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt

From: "Trevor Freeman" <[email-masked]>
Date: Wed, 24 Apr 2002 16:44:23 -0700

Mike,
All you are saying is that the server needs to clarity the reason for
the inability to validate the certificate. You objection seems to be
wording of the return state in the requirement document implying more
than is intended. Rather that naming them in the requirements document
valid and invalid, we can name them success and failure. Success means
the server was able to complete the client request, and failure means it
did not.

Trevor
-----Original Message-----
From: Michael Myers [mailto:[email-masked]] 
Sent: Wednesday, April 24, 2002 3:54 PM
To: Trevor Freeman; PKIX 
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt

Trevor,

I agree with you and Russ that from a state machine perspective,
a client will probably take the same action in both the unknown
and invalid cases.  However, from a server, or more importantly
a service perspective, I suspect there exists an appreciable
semantic difference  in a legal or liability sense between these
two states.

I've had the pleasure over the past few years of abundant
exposure to lawyers, bankers, regulators and other such types
regarding these and related issues.  I'm sure many of us share
that experience in one form or another.

Now, I'm no lawyer but given that exposure it seems to me that a
service (i.e. that which runs a server) is setting itself up for
disaster by asserting a digitally signed "invalid" when in point
of fact that service hasn't the data, jurisdiction or delegation
to make such an unequivocal assertion.

As a hypothetical, consider a party seeking damages to which an
invalid assertion is useful as evidence even though the
certificate in question is provably valid given access to the
relevant data.  That plaintiff could arguably find some service
that doesn't know diddly about the certificate to issue a
digitally signed "invalid" and there you go.  That TTP may have
just stuck its neck out.

I know that's probably a stretch, but not inconceivable given
some the purposes to which certs and sigs are today being
applied.  Better it seems by far to enable an "out" via unknown
even if at the other end, the client does nothing differently.

Valid and Invalid mean something very precise to my way of
thinking.  It means data was accumulated, a path was
successfully constructed, revocation information was checked and
the entire dataset checked according to 2459 and whatever else
might specified by the policy in place at the time between the
client and the server/service.  Break any one of those
assumptions and one can't assert invalid.  Hence we need
unknown.

Mike

> -----Original Message-----
> From: Trevor Freeman [mailto:[email-masked]]
> Sent: Wednesday, April 24, 2002 11:33 AM
> To: Michael Myers; PKIX
> Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
>
>
> Mike,
> I realise there has been several mailing on this
> topic, but so far no
> consensus.
> Apart form references to 2560, I have not seen much
> in the way of
> reasoned justification as to why we need another
> return code in DPV/DPD.
> All this additional return value is indicating is
> some kind of failure
> on the part of the server. We have defined the requirement for
> additional information on the error to be returned by
> the server to
> clarify the nature of the failure to the client. If
> you want to refine
> the defined list of sub-status reasons when we get to
> define the
> protocol then I am sure we can debate this more
> meaningfully then.
> However since one of the goals of the DPV protocol is
> to address
> constrained clients, then we have to be hard core on
> not complication
> the protocol.
>
> Trevor

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 24 Apr 2002 17:44:09 -0700

Trevor,

No, what I'm saying is that valid and invalid have precise
technical meanings that could be potentially relevant to an
arbitration panel if not a court of law.  The unknown state
affords a service provider or enterprise deploying a server the
means to escape out of binding itself into a situation that
could possibly put it at financial risk.

I could be totally wrong in that perception, but that's what I
think.  Several years ago it was just crypto and toolkits.
Today there's laws and regulations and jurisdictional forums
considering how this technology applies to societal factors.  I
for one think we need to be responsible in this regard.

Else maybe what you're talking about is more aligned with Peter
Gutman's certOK proposal.

Mike

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

> Sent: Wednesday, April 24, 2002 4:44 PM
> To: Michael Myers; PKIX