Subject: RE: DPD & DPV requirements - Recursion Issues

From: Peter Sylvester <[email-masked]>
Date: Thu, 11 Jan 2001 16:58:41 +0100 (MET)

> Content-Length: 3514
> 
> Wouldn't a DPD/DPV server solely carry out the task of discovering and
> validating paths, and possibly use other protocols (e.g., LPAP, OCSP, etc.),
> which might be recursive, to assist in this process? So unless sub-DPD/DPV
> servers take part in path discovery or validation I would not describe
> DPD/DPV as recursive.
> 

'Recursive' lay not be the right word, but you can have relaying
or delegation or proxying. 

In the above, replace 'OCSP' by DPV': - instaed of asking
for the revocation status, you ask for the validity status.
This isn't that different, and even in OCSP you already have
relaying.

---

From: "Covey, Carlin" <[email-masked]>
Date: Thu, 11 Jan 2001 08:17:58 -0800

Frank and Peter,

I'd be happy for someone to define a set of terms for use in this
context, if it would benefit the discussion.

The "transitive trust" issue that was referred to earlier arises in
the context of "relaying" DPV status.  The client asks server 1 to 
validate the status of a certificate, and server 1 "relays" some or
all of the validation process to server 2.  When the response comes
back from server 2, server 1 then prepares a response to the client
based wholly or in part on the information obtained from server 2.

When I originally used the term "recursion" I had in mind a recursive
data structure, i.e. a DPD response that contains another DPD
response that might in turn contain another DPD response.  This is one
method for returning the "relayed" status information to the client. 
This particular method raises the syntactic complexity issue that
was mentioned in a previous email.  This syntactic complexity is avoided
if server 1 extracts information from server 2's response and repackages 
it into a nonrecursive data structure that it then sends to the client.
As I mentioned in an earlier email, one advantage of the recursive data
structure is that it allows the optional timestamp on the embedded DPD
responses to be retained.

Regards,

Carlin

------------------------------

- Carlin Covey
  Cylink Corp.

---

From: Frank Balluffi <[email-masked]>
Date: Thu, 11 Jan 2001 09:00:10 -0800

> it into a nonrecursive data structure that it then sends to 

I agree. I like the following:

client
  |
  | (DPD/DPV)
  |
server 1
  |
  | (supporting protocol (e.g., OCSP))
  |
server 2
  |
  | (supporting protocol)
  |
server 3

or

      client
        |
        | (DPD/DPV)
        |
      server 1
  |             |
  |             |
  |             |
server 2     server 3

more than:

client
  |
  | (DPD/DPV)
  |
server 1
  |
  | (DPD/DPV)
  |
server 2

Frank

> From: Covey, Carlin [mailto:[email-masked]]
> Sent: Thursday, January 11, 2001 11:18 AM
> To: [email-masked]
> > validating paths, and possibly use other protocols (e.g., 
> LPAP, OCSP,
> etc.),

---

From: "Covey, Carlin" <[email-masked]>
Date: Fri, 12 Jan 2001 08:35:35 -0800

Vishal, Frank, Peter, et. al.

I agree with Vishal that this is a situation that can 
appropriately be termed "transitive trust."  "A" trusts 
the information returned by "B" who trusts the information 
returned by "C".  I'm not making any claims about whether
this is a good thing or a bad thing.  I'm sure the answer
would be different to different people and in different
circumstances.  Many human and machine relationships are
built upon transitivity:  "Any friend of yours is a friend
of mine." or more negatively, "Any enemy of yours is
a friend of mine."  

In this case, one point of view is that the client trusts 
server 1 to return a correct answer, and the client doesn't
know or care how server 1 obtained the information upon
which that answer is based.

Another point of view is that the client trusts the server
to not be malicious (e.g., it may be a server run by the 
client's company), but the client doesn't trust
the server to not be stupid (the client has dealt with
the server administrator before).  So the client may fear
that the server will not chose wisely when selecting other
servers to trust.

My preference is for server 1 to publicize the fact that
it trusts information obtained from certain other servers,
and the client can take that fact into account when deciding
whether to trust server 1.

Regards

Carlin

------------------------------------
- Carlin Covey
  Cylink Corp.

-----Original Message-----
From: vishal jakhar [mailto:[email-masked]]
Sent: Friday, January 12, 2001 8:55 AM
To: Peter Sylvester; [email-masked]; [email-masked]
Subject: RE: DPD & DPV requirements - Recursion Issues

Dear Frank and Peter,
To my knowledge the term "Transitive trust" is definately there.
Since a client trusts server 1,any information that comes back from
it is treated as trusted, no matter what other parties are included 
in the response. And since I trust server 1 really does not mean 
that I should trust server 2,but since server 1 is trusting server 2
It forms a trust chain, in which I am trusting server 2 indirectly.
This indirect trust should be invisible to the client ,so that the 
client thinks that he is trusting only the party he trusts.
                 It is better to repackage the response instead 
of using a recursive approach, because the client should be unaware
of the recursion.
regards ,
Vishal .

<snip>

---

From: "Covey, Carlin" <[email-masked]>
Date: Fri, 12 Jan 2001 08:52:21 -0800

Peter,

See indented comment below.

-----Original Message-----
From: Peter Sylvester [mailto:[email-masked]]
Sent: Friday, January 12, 2001 2:58 AM
To: [email-masked]; [email-masked]
Subject: RE: DPD & DPV requirements - Recursion Issues

<snip>

[from Carlin's previous email]
> responses to be retained.

[from Peter's response]
Whatever is contained in a response, it is left untouched. 

     [Carlin's latest response]   OK, but what if there is no provision in
the 
     DPD response syntax for including an embedded DPD response?  The good
news
     is that the timestamp on the embedded DPD response is untouched.  The
bad
     news is that you can't include an embedded DPD response.  Catch
vingt-deux.

     Regards,  Carlin

---

From: Peter Sylvester <[email-masked]>
Date: Sun, 14 Jan 2001 13:43:26 +0100 (MET)

> >
> >I am not the best candidate to answer questions about DPD. I am mainly
> >interested in DPV (as some might imagine).
> >
> >Anyway, if I understand Mike Myers remark correctly, if a DPD server
> >is essentially untrusted, then it could basically just rewrite a relayed
> >response.
> 
> Yes, but that will be caught by the client of a DPD server, even a 
> DPV server that acts as a DPD client in performing it's function, as 
> Steve Hanna suggests.
> 
> >A DPD server might have performed an OCSP check or a DPV check (for example
> >to validate a CA cert.) The response should be sent back to the DPD
> >client, this can be used by the client to make a decision about the
> >acceptablity of the path.
> 
> An OCSP response if fair game. but I'm not sure I want the DPV 
> response to be used recursively, yet.

Hm, 

A DPV response has such an importance that it seems useful to keep
it as is when used by a client, even if this client uses the
content of the response to create some other statement or
whatever to its type of client. 

There are at least two elements in the response of a DPV:

- A authoritive statement about whether a cert is good or not.
- And a list of reasons, starting with the cert chain, crls,
  Ocsp responses. 

If a DPV server has acted as a DPV client either in delegation to
validate the same initial certificate, or to validate for
example the first CA cert in chain not just by using OCSP but by
using DPV, then not allowing it, *MUST NOT* be included,
in a response means what?

CA certs, CRLs, OCSP reponses are statement about the validity,
they already have a different nature, a DPV response doesn't
seem to be that far. 

Again, if an OCSP responder policy explains that
the actual status doesn't just say 'not revoked' but
'good and existing', then this statement is essentially
the response of a DPV.

Peter

---

From: Michael Myers <[email-masked]>
Date: Mon, 15 Jan 2001 18:22:08 -0800

Peter,

One thought at this point:

> Sent: Sunday, January 14, 2001 4:43 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> . . .

Section 2, "Delegated Path Validation", of draft-ietf-pkix-ocsp-valid-00.txt
specifies use of BasicOCSPResponse syntax.  This syntax enables but does not
mandate inclusion of chains or CRLs.

Mike