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

From: "Trevor Freeman" <[email-masked]>
Date: Wed, 24 Apr 2002 17:59:52 -0700

Michael,
Success and failure have precise technical meaning. The client is asking
either "can you validate this certificate" or "can you build a path with
this certificate" The server can succeed in that task - which implies
the certificate is valid or the server build a path, or the server
failed. Using these semantics, failure to comply with the clients
request on the server's part implies nothing about the certificate only
about the server ability, but retains a binary response which is simple
for the client to process.
We can add specific reasons for the failure in the protocol document
which allow the server to express whatever it wants about its
inadequacies.
Is that OK for now?

Trevor

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

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

> -----Original Message-----
> From: Trevor Freeman [mailto:[email-masked]]
> Sent: Wednesday, April 24, 2002 4:44 PM
> To: Michael Myers; PKIX
> Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
>
>
> 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 18:17:40 -0700

Trevor,

It is my firm belief that at a meta level we are faced
fundamentally with a trinary valued state variable.  I've yet to
hear a needs-based argument that dissuades me from that
conviction.  Maybe we should discuss offlist and spare the WG
further chatter.  My contact info is below.

Mike

Michael Myers
t: +415.819.1362

> Sent: Wednesday, April 24, 2002 6:00 PM
> To: Michael Myers; PKIX

---

From: Tony Bartoletti <[email-masked]>
Date: Wed, 24 Apr 2002 18:58:17 -0800

Seems you have two choices:

1.  Go with "Trinary Value", in which case the semantics are satisfied by

   a. Success_Valid
   b. Failure_Invalid
   c. Failure_Unknown

2.  Go with "Binary Value", using either

   a. Valid
   b. Invalid (see reason code for details)

   or

   a. Success
   b. Failure (see reason codes for details)

 From a state-machine point of view, even the latter choices are workable, 
ASSUMING that the indicated reason-codes are "reasonably 
standardized".  The only "client-side-reason" I can see for this 3-valued 
(or n-valued) response would be a case of clientware capable of 
automatically seeking a "second opinion" from another source, where the 
trinary "unknown" is returned (or the reason-code associated with the 
binary response indicates a possible transient lack of information.)

The "Server-side" argument for trinary response (not wanting to pronounce a 
certificate "invalid" given lack of information or authority) seems 
satisfied by Trevor's Success/Failure terminology, correct?

Cheers!

____tony____

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

> > > constrained clients, then we have to be hard core on

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 24 Apr 2002 20:02:51 -0700

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Tony Bartoletti
> Sent: Wednesday, April 24, 2002 7:58 PM
>
> . . .
>
> The "Server-side" argument for trinary response (not
> wanting to pronounce a certificate "invalid" given
> lack of information or authority) seems satisfied by
> Trevor's Success/Failure terminology, correct?
>
> Cheers!

Hi Tony,

I must respectfully disagree for reasons previously cited
pending a convincing needs-based argument.  Else perhaps what
we're really backing ourselves into is a variation of if not
precisely the semantics of Peter Gutman's OCSP-based certOK
mechanism.

Mike

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 25 Apr 2002 10:05:22 -0400

Tony:

Agree.  I like choice 2.

Russ

At 06:58 PM 4/24/2002 -0800, Tony Bartoletti wrote:

>The "Server-side" argument for trinary response (not wanting to pronounce 
>a certificate "invalid" given lack of information or authority) seems