Subject: Re: Matching CertIDs between OCSP requests and responses

From: [email-masked] (Peter Gutmann)
Date: Sat, 24 Mar 2001 04:19:44 (NZST)

Jeff Jacoby <[email-masked]> writes:

>Pardon my naivte, but couldn't the responder apply a different BER/DER
>encoding to CertID in its response, yet keeping the actual encoded values
>within a CertID identical?

Well, you couldn't use a different DER encoding (there's only one correct one),
and you wouldn't BER-encode signed data, so I doubt there's any real problem.

Peter.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 23 Mar 2001 19:09:46 -0500

Based on presentations by and discussions with various folks during 
the IETF meeting this week, I have some suggestions for DPD/DPV 
requirements that I would like to put forth for discussion.

1- a motivation for both DPD and PDV has been to reduce the bandwidth 
consumed by the path validation process. However, moving all of the 
parameters required for path validation between a server and a client 
is expensive in terms of bandwidth. Thus I think we should consider a 
suggestion Denis Pinkas made on the list a while ago. We could make 
ALL requests refer to a policy configured at the server, rather than 
allowing for explicit transmission of these parameters. To make this 
as flexible as the current proposals, we would have to add a new 
protocol, to allow a client to register a policy with a server, so 
that the client could later refer to that policy. We probably want a 
facility to inquire about a registered policy as well. We could 
proceed with the development of DPD/DPV protocols prior to having the 
policy registration and inquiry protocols defined, if we feel the 
need to, but I would prefer parallel development of such protocols. 
The bottom line would be much simpler syntax for the requests and 
responses for both DPD and DPV, and smaller message sizes.

2- Along the same line of reasoning, Denis rightly noted that the 
primary purpose of DPV is to provide the yes/no/maybe response to a 
query re a target certificate. Thus, we ought to have a compact 
message format to provide this response, and a separate message for 
retrieval of the supporting data for the response, e.g., for NR 
purposes.  He proposed this split, with a hash of the "evidence" in 
the short response, to tie the two together. I like this suggestion 
and propose that we adopt this model as part of out requirements. Of 
course, we need the protocol for retrieving the evidence as well, to 
make the system complete.

3- we still have some significant disagreement about the nature of 
the path validation controls to be used for both services, but 
especially for DPD. Related to this disagreement is the issue of 
whether an DPD should support incremental queries relative to the 
same target certificate. I don't think we have seen a concise, 
comprehensive description of the application model where such an 
incremental approach is warranted, so I solicit the proponents of 
this approach to provide such a description, so that we can resolve 
this issue.

I'm off on vacation next week, see you later,

Steve

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 23 Mar 2001 17:20:33 -0800

Steve,

Speaking from the OCSP perspective, our formulations of OCSPv1 and OCSPv2
implicitly assumed and continues to assume that policy management between
relying parties and validating parties is out of scope.  We of the OCSP team
agree that the parallel development of such protocols is strongly preferred
vice deltas to OCSPv2.

I have no problem with an optional evidentiary hash in a DPV response if
it's client-precipitated.  As Denis and I had discussed earlier this week,
some environments may prefer this to the constant reiteration by a server of
a full chain or other policy indicators (e.g. the full text of a policy
document).  We will take this as a requirement and study how best to fold
this requirement into the current OCSPv2 technical framework.

When you refer to "incremental queries relative to the same target
certificate" are you speaking to the currently proposed retryReference
mechanism?

Mike

From: Stephen Kent [[email-masked]]
Sent: Friday, March 23, 2001 4:10 PM
To: [email-masked]
Subject: some thoughts re DPD and DPV

Based on presentations by and discussions with various folks during the IETF
meeting this week, I have some suggestions for DPD/DPV requirements that I
would like to put forth for discussion.

1- a motivation for both DPD and PDV has been to reduce the bandwidth
consumed by the path validation process. However, moving all of the
parameters required for path validation between a server and a client is
expensive in terms of bandwidth. Thus I think we should consider a
suggestion Denis Pinkas made on the list a while ago. We could make ALL
requests refer to a policy configured at the server, rather than allowing
for explicit transmission of these parameters. To make this as flexible as
the current proposals, we would have to add a new protocol, to allow a
client to register a policy with a server, so that the client could later
refer to that policy. We probably want a facility to inquire about a
registered policy as well. We could proceed with the development of DPD/DPV
protocols prior to having the policy registration and inquiry protocols
defined, if we feel the need to, but I would prefer parallel development of
such protocols. The bottom line would be much simpler syntax for the
requests and responses for both DPD and DPV, and smaller message sizes.

2- Along the same line of reasoning, Denis rightly noted that the primary
purpose of DPV is to provide the yes/no/maybe response to a query re a
target certificate. Thus, we ought to have a compact message format to
provide this response, and a separate message for retrieval of the
supporting data for the response, e.g., for NR purposes.  He proposed this
split, with a hash of the "evidence" in the short response, to tie the two
together. I like this suggestion and propose that we adopt this model as
part of out requirements. Of course, we need the protocol for retrieving the
evidence as well, to make the system complete.

3- we still have some significant disagreement about the nature of the path
validation controls to be used for both services, but especially for DPD.
Related to this disagreement is the issue of whether an DPD should support
incremental queries relative to the same target certificate. I don't think
we have seen a concise, comprehensive description of the application model
where such an incremental approach is warranted, so I solicit the proponents
of this approach to provide such a description, so that we can resolve this
issue.

Steve

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 23 Mar 2001 17:42:04 -0800

At 7:09 PM -0500 3/23/01, Stephen Kent wrote:
>We could make ALL requests refer to a policy configured at the 
>server, rather than allowing for explicit transmission of these 
>parameters. To make this as flexible as the current proposals, we 
>would have to add a new protocol, to allow a client to register a 
>policy with a server, so that the client could later refer to that 
>policy. We probably want a facility to inquire about a registered 
>policy as well.

This sounds horrendously complex. To date, the IETF has had near-zero 
success with defining policy protocols, with policy working groups 
pretty much being unable to get closure. The method promoted in SCVP 
(can give individual policy info in requests or can use aggregated 
OIDs) seems much more sensible than forcing all clients to know (or, 
worse, discover and push) the policies on the server.

The number of policies a typical client wants will probably be few 
(most likely, just roots). Why make this so much more complicated 
than needed?

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Liaquat Khan" <[email-masked]>
Date: Sat, 24 Mar 2001 11:12:57 -0000

some thoughts re DPD and DPVI'm not against the idea of having a (validation) policy registered on the server, which the client refers to in its request message.  However, IMO would it not be more practical for the CA which issued the certificate to be responsible for defining this policy and registering it directly with its validation server?  This may remove some of the complexity of each client having its own policy and a protocol for registering this at the server.    The client would only need to refer to the appropriate policy, which will be based on the target certificate being checked.   Just some initial thoughts...

Regards,
Liaquat

  ----- Original Message ----- 
  From: Stephen Kent 
  To: [email-masked] 
  Sent: Saturday, March 24, 2001 12:09 AM
  Subject: some thoughts re DPD and DPV

  Based on presentations by and discussions with various folks during the IETF meeting this week, I have some suggestions for DPD/DPV requirements that I would like to put forth for discussion.

  1- a motivation for both DPD and PDV has been to reduce the bandwidth consumed by the path validation process. However, moving all of the parameters required for path validation between a server and a client is expensive in terms of bandwidth. Thus I think we should consider a suggestion Denis Pinkas made on the list a while ago. We could make ALL requests refer to a policy configured at the server, rather than allowing for explicit transmission of these parameters. To make this as flexible as the current proposals, we would have to add a new protocol, to allow a client to register a policy with a server, so that the client could later refer to that policy. We probably want a facility to inquire about a registered policy as well. We could proceed with the development of DPD/DPV protocols prior to having the policy registration and inquiry protocols defined, if we feel the need to, but I would prefer parallel development of such protocols. The bottom line would be much simpler syntax for the requests and responses for both DPD and DPV, and smaller message sizes.

  2- Along the same line of reasoning, Denis rightly noted that the primary purpose of DPV is to provide the yes/no/maybe response to a query re a target certificate. Thus, we ought to have a compact message format to provide this response, and a separate message for retrieval of the supporting data for the response, e.g., for NR purposes.  He proposed this split, with a hash of the "evidence" in the short response, to tie the two together. I like this suggestion and propose that we adopt this model as part of out requirements. Of course, we need the protocol for retrieving the evidence as well, to make the system complete.

  3- we still have some significant disagreement about the nature of the path validation controls to be used for both services, but especially for DPD. Related to this disagreement is the issue of whether an DPD should support incremental queries relative to the same target certificate. I don't think we have seen a concise, comprehensive description of the application model where such an incremental approach is warranted, so I solicit the proponents of this approach to provide such a description, so that we can resolve this issue.

  Steve

---

From: "Carlin Covey" <[email-masked]>
Date: Sat, 24 Mar 2001 14:26:20 -0700

Paul and Steve,

I agree that the DPD and DPV protocols should be simplified by
including just a reference to a server-resident path-validation
policy.  I also agree with Paul that a typical client will
make a choice among very few policies.  In fact, most clients 
will never make a choice.  The clients and servers will be 
pre-configured with one policy per client-type per enterprise.  
Simply including one policy OID in the request (possibly echoed 
in the response) will satisfy the great majority of use cases.  

Paul points out the near-zero success-rate of policy protocols.
DPD/DPV should not be made into a quasi-policy-protocol by 
including explicit policy information in the requests.  An OID
will do.  If there remains a need for client-configuration of 
server-resident policies, put that in a separate protocol as 
Steve has suggested.  

Let's proceed with a simplified, low-bandwidth DPD/DPV that is as 
free as possible of the burden of policy configuration.

-  Carlin Covey
   Cylink Corporation 

-----Original Message-----
From: Paul Hoffman / IMC [mailto:[email-masked]]
Sent: Friday, March 23, 2001 6:42 PM
To: Stephen Kent; [email-masked]
Subject: Re: some thoughts re DPD and DPV

--Paul Hoffman, Director

---

From: "Carlin Covey" <[email-masked]>
Date: Sat, 24 Mar 2001 14:46:30 -0700

some thoughts re DPD and DPVLiaquat,

I agree with you that it may be more appropriate for authorities other than
the client
to configure the path-validation policies.  The client would then be free to
choose one
of these already-configured policies via the appropriate OID in the request
(or, if the
client didn't like any of the policies, to either cause another one to be
configured at
the server in some out-of-band fashion, or to do the path validation
itself).  The CA
who issued the target certificate might be an appropriate authority to
configure some
policies, but the RP's own CA might be more appropriate in other situations.
In the
case of a DPV/DPD server that supports a particular enterprise, a likely
candidate
is the human authority who manages the DPV/DPD server for the enterprise.
-  Carlin Covey
   Cylink Corporation

  -----Original Message-----
  From: Liaquat Khan [mailto:[email-masked]]
  Sent: Saturday, March 24, 2001 4:13 AM
  To: [email-masked]; Stephen Kent
  Subject: Re: some thoughts re DPD and DPV

  I'm not against the idea of having a (validation) policy registered on the
server, which the client refers to in its request message.  However, IMO
would it not be more practical for the CA which issued the certificate to be
responsible for defining this policy and registering it directly with its
validation server?  This may remove some of the complexity of each client
having its own policy and a protocol for registering this at the server.
The client would only need to refer to the appropriate policy, which will be
based on the target certificate being checked.   Just some initial
thoughts...

  Regards,
  Liaquat

    ----- Original Message -----
    From: Stephen Kent
    To: [email-masked]
    Sent: Saturday, March 24, 2001 12:09 AM
    Subject: some thoughts re DPD and DPV

    Based on presentations by and discussions with various folks during the
IETF meeting this week, I have some suggestions for DPD/DPV requirements
that I would like to put forth for discussion.

    2- Along the same line of reasoning, Denis rightly noted that the
primary purpose of DPV is to provide the yes/no/maybe response to a query re
a target certificate. Thus, we ought to have a compact message format to
provide this response, and a separate message for retrieval of the
supporting data for the response, e.g., for NR purposes.  He proposed this
split, with a hash of the "evidence" in the short response, to tie the two
together. I like this suggestion and propose that we adopt this model as
part of out requirements. Of course, we need the protocol for retrieving the
evidence as well, to make the system complete.

    3- we still have some significant disagreement about the nature of the
path validation controls to be used for both services, but especially for
DPD. Related to this disagreement is the issue of whether an DPD should
support incremental queries relative to the same target certificate. I don't
think we have seen a concise, comprehensive description of the application
model where such an incremental approach is warranted, so I solicit the
proponents of this approach to provide such a description, so that we can
resolve this issue.

    Steve

---

From: "Liaquat Khan" <[email-masked]>
Date: Sun, 25 Mar 2001 15:16:26 +0100

some thoughts re DPD and DPVThe options you propose also make sense to me.  One question though, how does the RP know which policies have been pre-configured on the server?  

Maybe, the RP application could also be pre-configured with the OIDs of the (validation) policies which are acceptable to it.  It could then uses these in its request messages.

Regards,
Liaquat

  ----- Original Message ----- 
  From: Carlin Covey 
  To: Liaquat Khan ; [email-masked] ; Stephen Kent 
  Sent: Saturday, March 24, 2001 10:46 PM
  Subject: RE: some thoughts re DPD and DPV

  Liaquat,

  I agree with you that it may be more appropriate for authorities other than the client
  to configure the path-validation policies.  The client would then be free to choose one
  of these already-configured policies via the appropriate OID in the request (or, if the
  client didn't like any of the policies, to either cause another one to be configured at
  the server in some out-of-band fashion, or to do the path validation itself).  The CA
  who issued the target certificate might be an appropriate authority to configure some
  policies, but the RP's own CA might be more appropriate in other situations.  In the
  case of a DPV/DPD server that supports a particular enterprise, a likely candidate
  is the human authority who manages the DPV/DPD server for the enterprise.
  -  Carlin Covey
     Cylink Corporation 

    -----Original Message-----
    From: Liaquat Khan [mailto:[email-masked]]
    Sent: Saturday, March 24, 2001 4:13 AM
    To: [email-masked]; Stephen Kent
    Subject: Re: some thoughts re DPD and DPV

    I'm not against the idea of having a (validation) policy registered on the server, which the client refers to in its request message.  However, IMO would it not be more practical for the CA which issued the certificate to be responsible for defining this policy and registering it directly with its validation server?  This may remove some of the complexity of each client having its own policy and a protocol for registering this at the server.    The client would only need to refer to the appropriate policy, which will be based on the target certificate being checked.   Just some initial thoughts...

    Regards,
    Liaquat

      ----- Original Message ----- 
      From: Stephen Kent 
      To: [email-masked] 
      Sent: Saturday, March 24, 2001 12:09 AM
      Subject: some thoughts re DPD and DPV

      Steve

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 26 Mar 2001 11:18:17 +0200

Carlin,

> policy.  

Fine.

> I also agree with Paul that a typical client will

I do not believe so. The policy is application dependent. One application
will usually be linked with one policy. Since a client will normally support
multiple applications, he will use more than one policy.

> in the response) will satisfy the great majority of use cases.

As I proposed during the last IETF meeting, if the client does not indicate
anything about the policy to be used in his request, then the server should
indicate what has been used.

> including explicit policy information in the requests.  

See my proposal above. The client MAY include a reference or the client
SHOULD include a reference. 

> An OID

Fine.
 
> free as possible of the burden of policy configuration.

Agreed.

Regards,

Denis

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 26 Mar 2001 11:05:34 +0100

Steve,

Just picking up on this one...

> 3- we still have some significant disagreement about the nature of the path validation controls to
> be used for both services, but especially for DPD. Related to this disagreement is the issue of
> whether an DPD should support incremental queries relative to the same target certificate. I don't
> think we have seen a concise, comprehensive description of the application model where such an
> incremental approach is warranted, so I solicit the proponents of this approach to provide such a
> description, so that we can resolve this issue.

I'm glad to see that we're tending towards the "abbreviated" DPD/DPV protocol,
rather than exhaustively specifying options on the wire. The retryReference field 
in DPD is, I believe, necessary regardless of whether we take this sensible 
approach or the more verbose approach. 

Basically, the issue is that path constuction policies can never be "complete", 
in the sense that there is always the possibility that two paths exist which 
satisfy the policy, but where the application prefers one path over the other.
(BTW: I simply assert this, I'm not saying I've a proof.)

The inclusion/exclusion of a non-critical application-specific extension
in one certificate in the path can cause this, as can overlaps in the
validity fields of certificates (which some application may choose to care
about).

What you're left with is the fact that its not actually possible (never
mind wise:-), to include in a protocol every possible thing that an application 
may care about related to path construction policy.

Without the retryReference field, the server is basically leaving any such
application stranded. If the application retries the "meat" of the request, 
then it'll get the same response. The application's only choice is to start
"guessing" variations on the request which might produce a different response.
Not a good idea.

Some folks might counter that this just means that the path construction policy
being used is "bad", and say that we should just introduce a new path construction
policy. Well, as you can see from the above I don't think that works in general,
and even if it did work in lots of cases a) we might end up generating *lots*
of path construction polices, a recipie for confusion, and b) the resulting 
DPD protocol would still suffer from the problem described in the previous 
paragraph, which sounds like a bad characteristic of a "query" style 
protocol.

So, we're left with a problem of finding "another", or equally, "the next"
path that satisfies the relevant path construction policy, and of managing
the restricted state information necessary for this purpose. (As I said at
the meeting, the state in question need *not* be DPD-client specific, but is
rather returned-path-specific, a different thing entirely. A hash over the 
path is probably a good implementation choice for the retryReference value.)

That's what the retryReference allows - the client, for whatever reason,
says: "didn't like that path"; the server, if it supports the function (which
I think it should, at least to handle overlapping validity periods), tries
to find another path and if it does returns that (with a new retryReference).

You said concise, so I'll stop now. I can only hope this is comprehensive too:-)

Hoping this doesn't turn into another of those endless threads...
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 26 Mar 2001 12:30:57 +0200

Steve (Farrell),

Steve will not reply soon to your e-mail because he advertised that he will
be off on vacation this week. So do not assume that silence from him means
acceptance. :-)

> Steve (Kent),

I noticed that your were the single one at the IETF meeting advocating the
need for the retryReference. There migh be other individuals present at the
meeting or people on the mailing list supporting this idea as well, but up
to now they have remain silent. :-)

> (BTW: I simply assert this, I'm not saying I've a proof.)

Since the client may wish to apply additional conditions on the
certification path that he gets back, e.g. looking for the presence of
private extensions, then, in theory, what you say is certainly possible.
However, as Steve (Kent) noticed during the meeting, in practice, no more
than four certification path would ever be returned. 

So the basic question that I ask you is the following: why not retrurn once
all these four certification paths ? 

Steve introduced a nice notion, i.e. to limit the number of paths that the
client is prepared to accept. It could then be one only or five. If you get
four what asking for five, this means that you got the best the sever could
do. 

For that reason I do not see why we should support a statefull server, which
is what retryRefrence implies. :-(

Hoping that your next message can close this thread ...

Regards,

Denis

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 26 Mar 2001 12:26:10 +0100

Denis,

> to now they have remain silent. :-)

That never seems to bother you, so I'm ok with it in this case:-)

> all these four certification paths ?

1) the server probably won't have all of 'em to start with (is every server
implementation going to do an exhaustive search for every new request? what
about when 1 of 6 LDAP servers doesn't respond to the DPD server?)

2) I disagree about the "4" - you're ignoring different validity periods and
also caCertificates which, if they exist, can lead anywhere if the client
doesn't specify trust points

3) unnecessary and inefficient bloat: given that 90% (or whatever) of the time 
any path is a fine answer - we shouldn't bloat 100% of responses for the sake 
of a small number of cases

> is what retryRefrence implies. :-(

"Statefull server" is an overstatement:-) I'd bet that any sensible DPD server
code would want to remember paths it had sent in response to requests 
anyway (for speed and anti-DoS reasons). retryReference just leverages that.

Stephen.

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 26 Mar 2001 15:01:24 +0200

Steve,

(deleted stuff)

> about when 1 of 6 LDAP servers doesn't respond to the DPD server?)

You have deleted one paragraph from my previous e-mail that provides you
with an answer. I copy here again for you:

" Steve introduced a nice notion, i.e. to limit the number of paths that the
client is prepared to accept. It could then be one only or five. If you get
four what asking for five, this means that you got the best the sever could
do." 

If you ask for one path, then you will not get more than one (you may get
none !). If you ask for three paths, but 1 of 6 LDAP servers doesn't
respond, 
then you will only get two paths. At some point of time in the future you 
might get more. So I do not see that there is a problem here.

> doesn't specify trust points

You are ignoring the fact that if the client does not specify trust points,
the server will. If the client is not pleased with these trust points, then
it
should specify itself the trust points. AFAIR, you did not disagreed with
Steve during the meeting about the number of paths that, in practice, would
be returned, taking into account the existence of cross-certificates. 

> of a small number of cases

If the criteria is finely tuned, then you are right and only one path will
be returned. If the criteria is "broad", e.g. three root keys with no other
constraints, then you may get more and any path is a fine answer to the
question raised, but not any more when applying additional local conditions.

> anyway (for speed and anti-DoS reasons). retryReference just leverages that.

I agree with you that "statefull server" might be an overstatement. Let us
speak of cache management. I would think that it may be appropriate for
efficiency reasons to keep track of already found paths. This does not mean
that the leaf certificate must be kept, but that all the CA certificates
above that path might be kept. Now this cached information should not be
associated with a retryReference number, so that *any* subsequent client can
get advantage of a speed improvement as soon as the CA from the leaf
certificate is the same. However, all these details are implementation
details, not visible at a protocol level. Hence we do not need to support a
retryReference number.

Regards,

Denis

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 26 Mar 2001 15:13:22 +0100

Denis,

> four what asking for five, this means that you got the best the sever could

What's the server supposed to do when the client says "5"? Is it supposed
to find all possible paths and return just 5? If so, the protocol doesn't
have a way for the client to recover if the client doesn't like all 5
returned. 

Or, is the server supposed to do whatever it likes (say finding
one) and send that back? In that case, the client who doesn't like the
result has to at some point increase the number in the request. But
hang on, that server already has one path that satisfies the request,
so it'll just send that back and never go looking for more paths. (Unless
the server is stateful per-client of course:-)

Basically, you're not sending the right signals but developing a protocol
which can lead to a kind of livelock (maybe that's not the right term 
though? http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?livelock defines it).

retryReference or an equivalent mechanism is needed and I haven't seen
any other worked out proposal for an equivalent mechanism. I'm sure one 
could be proposed, it hasn't so far (or send the URL if I missed it).

> be returned, taking into account the existence of cross-certificates.

But the server hasn't told the client which trust paths it picked, so if 
the client asks again then the client has no way to say that it didn't like 
the previous answer.

> question raised, but not any more when applying additional local conditions.

This is the "that's a bad path construction policy" argument I mentioned
in my first mail.

> certificate is the same. 

There's nothing to prevent implementations doing such but that level of
cache management does not need to be visible in the protocol. The path
level does however due to the inherent "incompleteness" of path construction 
policy.

> However, all these details are implementation

We clearly disagree.

I think one of the things that Steve K. is keen we do more of is think about
state machines. IMO, the retryReference is a useful trick that matches well with
the state machine folks would implement (and which probably does need more work
in the ocspv2 draft). It seems that the putative alternative (client says: "I'll 
take up to 5") leads to a state machine which (admittedly in rare cases) causes 
the protocol to fail to do its job.

In any case, the ocspv2 proposal contains the retryReference for now and I think 
we've aired the arguments enough for today at least. Probably better to look at
it again in the next draft of ocspv2 and see what we all think then.

Stephen.

---

From: "Carlin Covey" <[email-masked]>
Date: Mon, 26 Mar 2001 08:40:13 -0700

Denis,

When I said "client-type" in my previous email, I meant email-client,
browser, VPN-client etc.  I should have said "application."  I think we
are in agreement on this point.  Sorry for the confusion.

Regards,

Carlin

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Monday, March 26, 2001 2:18 AM
To: Carlin Covey
Cc: Paul Hoffman / IMC; Stephen Kent; [email-masked]
Subject: Re: some thoughts re DPD and DPV

<snip>

<snip>

---

From: "Carlin Covey" <[email-masked]>
Date: Mon, 26 Mar 2001 09:23:11 -0700

Denis and Stephen,

Sorry to add on to this thread but ....

[Denis]: Steve introduced a nice notion, i.e. to limit 
         the number of paths that the client is prepared 
         to accept. It could then be one only or five. 
         If you get four what asking for five, this means 
         that you got the best the sever could do. 

         For that reason I do not see why we should support 
         a statefull server, which is what retryRefrence 
         implies. :-(

[Carlin]: Denis, suppose a client used Steve Kent's nice notion,
         and requested two paths, but wasn't happy with either 
         of them.  Does the client now ask for four paths (knowing 
         that the first two of them will be the two that it has
         already seen), or should the server be "stateful" and
         and return the next two paths that it hasn't already sent?
         The first option wastes bandwidth, the second option 
         requires that the server maintain state.  The client 
         could ask for four paths initially, but the client may 
         be happy with the first of the four paths, in which case 
         sending three additional paths is a waste of bandwidth.  

[Denis]: I noticed that you [Stephen Farrell] were the single one 
         at the IETF meeting advocating the need for the retryReference. 
         There might be other individuals present at the meeting or 
         people on the mailing list supporting this idea as well, but 
         up to now they have remain silent. :-)

[Carlin]: This is Carlin making some noise.    ;-)   
         retryReference helps to maintain synchronization between
         request and the server's state in the case of lost or delayed 
         requests or responses.  Even if Steve's nice notion were 
         implemented, I think you would still want a mechanism like 
         retryReference (un;ess you were willing to put up with 
         resending previously sent paths). 

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 29 Mar 2001 19:17:38 +0200

Steve,

Since Steve Kent is not present this week, I have refrained to answer too
quickly so that we can continue this thread with him when he comes back. 

 
> one) and send that back? 

You have provided yourself the right answer to your question just below:

> In that case, the client who doesn't like the
> result has to at some point increase the number in the request. 

> But hang on, that server already has one path that satisfies the request,

The server will return the previous answer(s) and more paths whenever
possible until the number of paths that has been requested has been reached.
So no "stateful per-client" functionality is needed. :-)

> the client asks again then the client has no way to say that it didn't like

When the client does not specify trust points, the server will. If
the client does not like the trust point chosen by the server, he may then
specify or *change the validation conditions*, e.g. the trust point(s), the
root key(s), the associated name and/or policy constraints or the validation
policy.

If these changes in the selection of the validation policy are done, then
the client will get different results. We should no forget that DPD clients
are PKI aware, since they perform the validation themselves, so they will
certainly be able to adjust the request parameters to their needs. 
 
> state machines. 
> IMO, the retryReference is a useful trick that matches well with

It not because it was there in version -02, that it should be maintained in
the next version, version -03. The ocspv2 draft is no more than a draft for
discussions. :-)

Using your terminology, my conclusion, at this time, would be:

A "stateful per-client" server can be avoided:

1) by specify the maximum number of paths that should be returned, and
2) by refining the parameters of the validation policy, in case the first
   request has too broad parameters.

The advantage of being able to get more that one path at a time may also
save the number of exchanges.

However, don't forget that is more a case study, since currently, in
practice, they are not so many paths from a given leaf certificate 
to one root key. :-)

Regards,

Denis