Subject: RE: Open issue: DPV relay

From: Ambarish Malpani <[email-masked]>
Date: Thu, 04 Apr 2002 17:44:27 -0800

Tim,
    I agree on this - DPV relaying should be supported. I don't
think it imposes any additional requirements on the protocol.
You wouldn't normally get into loops unless a server were pretty
badly misconfigured.

In general, the way most OCSP servers work is that they respond
for a set of CAs. For others, they either go to a URL specified
by the client application or one configured in the server itself.

It is possible to set up loops that can have server A ask B who asks
A, but I haven't seen this happen practically.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Chief Architect                                          650.567.5457
ValiCert, Inc.                                  [email-masked]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Tim Polk [mailto:[email-masked]]
> Sent: Thursday, April 04, 2002 3:11 PM
> To: [email-masked]
> Cc: Peter Sylvester
> Subject: Open issue: DPV relay
> 
> 
> 
> Peter Sylvester has stated a requirement for DPV servers to 
> relay requests 
> to one another:
> 
>  >
>  >There is a requirement, similar as for OCSP caches,
>  >that server just relays a request to another. This had been
>  >discussed several times, the differences had only been to
>  >what degree the relaying should become visible; whether one
>  >server can rewrite/resigns the answers of another etc.
>  >Relaying via cache is an obvious feature in many OCSP 
> implementation,
>  >how do they protect itself against loops between two servers?
>  >
> 
> I believe this is an open issue, and would like to start a 
> new discussion 
> thread limited to this topic.
> 
> As I understand Peter's scenario, there are three mutually 
> trusting DPV 
> servers.  If a server cannot satisfy a request directly, it 
> may relay the 
> request to a different server.  We'll assume the server is 
> smart enough not 
> to relay a request back to the requester.  (That is, if 
> server A relays a 
> request to Server B, B may relay it to Server C but not A.)
> 
> (1) Assume Alice requests a valid path for Bob's certificate 
> from Server A, 
> when none exists.
> (2) Server A relays the request to Server B, since it cannot 
> satisfy it 
> directly. (A could have chosen Server C; it is irrelevant.)
> (3) Server B relays the request to Server C, since it cannot 
> satisfy it 
> directly.  (C could not choose A, since it was the requester.)
> (4) Server C relays the request to Server A, since it cannot 
> satisfy it 
> directly.  (A could not choose B, since it was the requester.)
> 
> At this point, either A must maintain state and recognize 
> that the request 
> has cycled around or the protocol has to handle this by maintaining a 
> history list.
> 
> Peter, please confirm that I have characterized the problem 
> correctly (or 
> post the right scenario)!  I am not personally convinced that blind 
> relaying amongst DPV servers is a requirement.
> 
> IMHO, DPV relaying would be limited to the scenario where 
> each Server was 
> authoritative for a particular community (perhaps based on 
> privately held 
> status information).  Alice directs all requests to Server A 
> to simplify 
> her life.  Server A would be able to determine which server 
> (B or C) could 
> possibly satisfy the request based on Bob's certificate.
> 
> Even though relaying occurred, Server A acted as a simple DPV client, 
> imposing no additional requirements...
> 
> Thanks,
> 
> Tim Polk
>

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 5 Apr 2002 14:01:54 +0200 (MET DST)

Thanks Tim for trying to summarize the open points:

Actually there are two open issues concerning 'relaying'.   

*** Issue 1 ***: 

This is about loop detection and control (of blind relaying??)

> 
> At this point, either A must maintain state and recognize that the request 

You can already have a loop between two entities. The protocol
is not necessairily symmetric. You may not necessarily know that the
entity you get the request from is the same that you will contact
via an URL etc. 

Yes, and I see a difficulty to maintain state, since the only information
you might count on, is the certificate to be validated, and there could be
two valid requests for the same cert. 
 
> Peter, please confirm that I have characterized the problem correctly (or 
What do you mean by 'blind relaying'?  

> IMHO, DPV relaying would be limited to the scenario where each Server was 
> authoritative for a particular community (perhaps based on privately held 
> status information).  Alice directs all requests to Server A to simplify 
> her life.  Server A would be able to determine which server (B or C) could 
Even if A know that either B or C will finally satisfy a request, A
cannot know whether B or C will try to contact another server etc.
for whatever reason. 

Thus, some mechanisms of state keeping or trace or hop count or 
is needed, statekeeping would require ... left as an exercise
to developpers.

Thanks to Ambarish's message about potential OCSP problems. The
fact that in real life it doesn't happen very often happens ... :-)

I'd propose to add a text somewhere?

  In case a DPV (or DPD) service chooses to relay the request to
  another service, a method to detect and prohibit loops MUST
  be applied. 

*** Issue 2 ***:

A DPV server may want to determine the validity status of 
an intermediate CA certificate, (or even obtain responses
from other DPV servers confirming a validity decision).

Another scenario is a company server that validates an
certificate of another company, it asks the other companies
server, and obtains a result.  The server *may* choose to
create its own response withour revealing the response
from the other server (blind relaying?), but it may also 
choose to give the answer back to the client allow to maintain
a proof that the 'other company' has cooperated. 
 
Simular to OCSP responses or CRLs which represent
assertions about the validity of some cert, a DPV response
is also such kind of assertion. 

I see a requirement that a server may want to add 
DPV responses in his response in order to create a complete 
picture of all the assertions he obtained. 

Answers from Denis always seem to indicate that
a DPV response MUST NOT be included in a final response
(since *we* do not support relaying). 

I do not see an essential difference between 
a CRL repository, an OCSP response and a DPV response.
There I propose to add behind  

"...  As an 
example, an S/MIME message might include such information, and the 
client can simply copy that information into the DPV request."

the text:  

DPV responses may use information obtained by other DPV transactions 
performed by the DPV server in order to determine the validity of 
some certificate in the path. The server MUST be able to include 
such response in its own final response. 

Or to replace in the preceding paragraph 'revocation information'
by "'status information' such an revocation information of CRLs
or OCSP but also other DPV responses.".  

*** A little nit-picking:

Would the authors try and avoid characters like "Æ" instead 
of "'" as in DPV serverÆs.

---

From: Tim Moses <[email-masked]>
Date: Fri, 5 Apr 2002 08:18:54 -0500

Colleagues - For the sake of generality, I prefer that the protocol be
designed to handle paths of arbitrary length, rather than being "hard-wired"
to a length of two.  As Tim points out, this can be achieved quite easily by
allowing a "trace" field in the request.  All the best.  Tim.

-----------------------------------------
Tim Moses
Tel: 613.270.3183

-----Original Message-----
From: Ambarish Malpani [mailto:[email-masked]]
Sent: Thursday, April 04, 2002 8:44 PM
To: 'Tim Polk'; [email-masked]
Cc: Peter Sylvester
Subject: RE: Open issue: DPV relay

Tim,

Regards,
Ambarish

---

From: Ambarish Malpani <[email-masked]>
Date: Fri, 05 Apr 2002 08:02:40 -0800

Hi Peter,
    I agree with your desire to have a DPV response included where
one would allow CRLs or OCSP responses to be included to prove
how a server obtained the status of a certificate.

Regards,
Ambarish

> From: Peter Sylvester [mailto:[email-masked]]
> Sent: Friday, April 05, 2002 4:02 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: Open issue: DPV relay
> 
> 
... (Stuff deleted)

> Would the authors try and avoid characters like "AE" instead 
> of "'" as in DPV serverAEs. 
> 
> 
> 
> 
> 
>    
>  
>

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 08 Apr 2002 17:05:16 +0200

Russ,

I fully agree with you: 

1) "I see no reason for the client to be made aware of an chaining or
    multicasting".

2) "I do not think that we should include referrals in the DPV system 
    at all".

Now, taking the scenario depicted by Peter, with some important changes:

 End user A asks server S1 "validate cert".
 client S1 asks server S2. 
 server S2 responds : don't know. 
 client S1 asks to another DPV server that it trusts, e.g. server S3.
 server S3 responds to client S1 : the certificate is valid.
 server S1 responds to end user A: the certificate is valid.

This is not referral, but it works fine with a list of servers trusted 
by server S1.

Denis

> Jim:
> 
> I am not talking about trust in the X.500 system.  I am talking about trust
> in a DPV server.  In my mind, the client asks one DPV server to perform an
> action.  The response should come back, signed by that DPV server, or it is
> an error from the client's perspective.
> 
> I see no reason for the client to be made aware of an chaining or multicasting.
> 
> I do not think that we should include referrals in the DPV system at all.
> 
> Russ
> 
> At 02:50 PM 4/5/2002 -0500, jim wrote:
> >A small addition, but X.500 directories also have the ability for
> >multicasting in
> >which case a number of other directories are queried for a certificate at
> >the same
> >time.  Multicasting requires the greatest amount of directory and system
> >overhead,
> >but gets the quickest returns; where chaining requires the least and
> >referral is
> >the slowest, so there should be support for all three in the DPV
> >capability.  There
> >are no associated trust issues with use of either of the three methods as
> >far as I
> >know.
> >Jim
> >
> >"Housley, Russ" wrote:
> >
> > > Steve:
> > >
> > > In the X.500 directory, they two communication models are called chaining
> > > referrals.  Peter has asked for chaining support.  You are asking whether
> > > referrals should also be supported.
> > >
> > > I can see cases where chaining might be helpful.  It does not change the
> > > client's trust model.  It asks a particular DPV server for a response, and
> > > it gets one (signed by the same server that it asked).
> > >
> > > I think that referrals complicate the trust model.  The client asks one DPV
> > > server, then that server suggests that a different server might be better
> > > able to help.  If the client chooses to ask that server, it will get back a
> > > response signed by the second server.  Does the client trust it only
> > > because the first server made a referral?  What information need to be
> > > stored by the client to prove that it was referred to this server? All of
> > > this is more complication than I want.
> > >
> > > Russ
> > >
> > > At 02:21 PM 4/5/2002 +0100, Stephen Farrell wrote:
> > >
> > > >*If* relaying support/capability is to be considered as a
> > > >MUST/SHOULD/MAY requirement for a DPV protocol, then should
> > > >re-direction be handled similarly? (Note: I'm not proposing
> > > >that it should be, just asking!)
> > > >
> > > >By re-direction I mean:
> > > >
> > > >Alice: Hey Bob - is this key good?
> > > >Robert: Dunno Alice - but Charlie might know.
> > > >Alice: Hey Charles - is this key good?
> > > >Chaz: Yep.
> > > >
> > > >Stephen.
> > > >
> > > >Tim Polk wrote:
> > > > >
> > > > > Peter Sylvester has stated a requirement for DPV servers to relay
> > requests
> > > > > to one another:
> > > > >
> > > > >  >
> > > > >  >Relaying via cache is an obvious feature in many OCSP implementation,
> > > > > I believe this is an open issue, and would like to start a new
> > discussion
> > > > > As I understand Peter's scenario, there are three mutually trusting DPV
> > > > > servers.  If a server cannot satisfy a request directly, it may
> > relay the
> > > > > request to a different server.  We'll assume the server is smart
> > enough not
> > > > > to relay a request back to the requester.  (That is, if server A
> > relays a
> > > > > (1) Assume Alice requests a valid path for Bob's certificate from
> > Server A,
> > > > > when none exists.
> > > > > (2) Server A relays the request to Server B, since it cannot satisfy it
> > > > > (3) Server B relays the request to Server C, since it cannot satisfy it
> > > > > (4) Server C relays the request to Server A, since it cannot satisfy it
> > > >--
> > > >____________________________________________________________
> > > >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: "Housley, Russ" <[email-masked]>
Date: Mon, 08 Apr 2002 12:21:49 -0400

Peter:

I think you are changing the context of my statement.  I said: "... the 
client asks one DPV server to perform an action.  The response should come 
back, signed by that DPV server, or it is an error from the client's 
perspective."

I did not say that the client could not have a trust relationship with more 
than one DPV server.

Russ

At 05:28 PM 4/5/2002 -0800, Peter Williams wrote:

>Todd,
>
>I do not believe we should formulate any
>particular use-model at this time, for DPV REQUIREMENTS;
>leaving aside the philosophical issue of
>whether use-modeling would or would not help IETF standards
>adoption. The requirements should prepare for
>protocol-specification, not establish operational
>usage constraints.
>
>The only valuable use-issues topics I can forsee that might
>serve us (in contradiction to the above) are precisely
>those that Ambarish mentioned: do what OCSP did,
>so succesfully in the Internet environment... for the
>same issue; and dont lets sucumb to the temptation to
>over-architect!
>
>--------------
>
>In my view, on Russ side comment, constraining DPV to
>require users to interact
>with a service provider at a single access-point is
>like setting the clock back on X.509, and requiring
>the world to adopt the Entrust use-model
>of PKC key management. Entrust's use-model makes
>for a fine and highly-manageable system, but it
>competes (successfully) with other domain-management
>models that are equally succesful in the wider Internet
>environment we server.
>
>The only trust issue for DPV requirments I can see
>is this:
>
>Just, as Sharon recently indicated, PMI's SOAs
>are trusted as authoritative for their policy
>scope, so DPV servers are trusted. PMI deals
>with privileges; DPV deals with remote processing
>of chains against validation policies. The two
>authority models are really identical, otherwise.
>
>Lets note that PMI didnt constrain an AC verifier to use
>only a single SOA-headed source of AC paths. So
>should the DPV requirements not constrain the
>DPV client from accepting results from
>any  set of (possibly (out of IETF scope) constained) DPV
>servers - whose service is provided at the
>access point to which the client is bound (including
>that operated, perhaps, by a simple-proxing or a
>chaining&resigning DPV server).
>
>
>From: todd glassey [mailto:[email-masked]]
>Sent: Friday, April 05, 2002 3:52 PM
>To: Housley, Russ; jim
>Cc: [email-masked]; Tim Polk; [email-masked]
>Russ is 100% dead on  but this is about the mechanics of the use model more
>than anything - let me demonstrate...
>
>----- Original Message -----
>From: "Housley, Russ" <[email-masked]>
>To: "jim" <[email-masked]>
>Cc: <[email-masked]>; "Tim Polk" <[email-masked]>;
><[email-masked]>
>Sent: Friday, April 05, 2002 12:42 PM
>The only way this would not want to be true is if the trust model between
>the requesting agents and the supplying agents had a pre-existing agreement
>that the trust supplying agent could look beyond its own services as sources
>of the trust model its looking for from this DPV server. It would then stand
>as a referred trust provider when it cannot satisfy the trust request
>itself.
>
>In fact from a use model perspective, it would seem that only the client
>could authotize this  for privacy reasons, and it seems that it would need
>to be on a per transaction basis (I.e. the Trust provider says " my trust
>processes cannon fulfill this request so I have passed it onward to someone
>that can" ... the only problem is that you run the potential that the  next
>link in the trust envelope would also not be able to satisfy this request
>either or coupdl get locked in a loop... so where does it stop???)
>
>The "what" of what you have now is a situation where the referring agent is
>going around and shopping for an external DPV agent who can and is willing
>to satisfy this trust validation request.  And this seems at best kinda
>clunky and potentially a real problem  over privacy and context information
>from the actual agent requesting this validation service.
>
>I suggest that becuase of this, that unless specifically authorized or
>requested from the client, that the DPV services should be restruicted to
>stay on a single platform... and it be the Client's responsibility to
>hierarchicly check out the trust element in question.
>
> >
> > Russ
>
>SNIP

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 9 Apr 2002 13:33:03 +0200 (MET DST)

> 
> So, in requirements language I guess I'd be arguing for something 
> like:
> 
> - A protocol SHOULD NOT require DPV clients to support relay or
>   re-direct (aka chaining or referral)
> - A protocol MAY require DPV servers to include support for 
>   relay and/or re-direct (aka chaining and/or referral)
> 
> Is that reasonable?

I agree with the second statement. 

Splitting the first into 

1a - A protocol SHOULD NOT require DPV clients to support relay
   (aka chaining)
1b - A protocol SHOULD NOT require DPV clients to support re-direct 
   (aka referral)

I agree with 1b. But with 1a I would like some explanation
What means 'a client support relay'. If you mean for example 
one of the following, I'd agree that this should not be required
for a client. 

- a client MUST indicate to a server the next hop
  in a chain. 

- a client MUST be able to authenticate the response from
  a second level server.
 
Are there other possibilities where a client has to
understand the fact that relaying or referral may occur or
had occured in order to prepare a request or to 
authenticate the response? 

Peter

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 9 Apr 2002 13:46:29 +0200 (MET DST)

> 
> Asking for a DPV relay is serious miss-interpreting the intent of DPV. 

I am confused: 

I am not sure but when I follow your following argument to the end,
a DPV client would need anything more than
just a authentic yes/no/unknown,  not even a path; what is the
purpose of giving a path to a client if the only thing it needs
is a assertion about the status of the certificate.

> In DPV you have a security association between the client and DPV
> server. The client is outsourcing its certificate trust decisions to DPV
> server. It is reasonable for the DPV server to employ any resource it
> deems necessary to complete the request from the client that the DPV
> server underwrites. The DPV server has to decide what resources it uses.

The term 'relaying' is related to the observation that
one of the possible resources is another DPV server. 
There is a possibility that the server turns itself into a 
client to another service and uses the same protocol.

One of the questions related to 'blind relaying' (if I 
correctly understand Tim's definition) is how to avoid loops
simply because the same or a similar request is used.

Another question is to what degree the details of who
has created the essence of the response is visible to a user. 
The initial server SHOULD be required to create a response 
that can be authenticated by the initial client. 

> None of this is of any consequence to the client as long as the decision
> is gives back to the client in accordance with the previously agreed
> policy. All the client wants is a decision according to the policy. A
> client could set up multiple SA to different DPV servers if it wanted
> higher assurance that the answer from the DPV server was the "right"
> answer - but that begs the question of why the client is not using DPD

I think that had been a lot discussion about use cases where
some clients want more than just a simple decision.   

A client may require to see some or all the elements (path, CRLs, OCSPs, 
DVCs, DPV responses) that have contributed to the decision. Furthermore, 
it is not necessarily the client who asked for them will exploit these 
information, they may be just kept in order to have a verifiable trace of 
what had contributed to the decision. 

This is independant from 'relaying' which can occur simply because the
protocol may be a convenient way to obtain information from what Denis calls
'a server that operates in the background'. 

Did I miss something?  
> Trevor
Peter S.

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 9 Apr 2002 19:10:53 +0200 (MET DST)

All,

I was told in private mail that in one of my previous messages
a statement that ended with a :-) could be misinterpreted
as a personal offense against Denis Pinkas.

I agree with that and hereby declare that there has been
no such intention.

The different styles of argumentation reminded me to
some discussions that happened almost 20 years ago
among former and actual colleagues; and I wanted
to share with all the anecdotical conclusions that had 
been drawn at that time.

Peter Sylvester

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 10 Apr 2002 18:35:13 +0200 (MET DST)

> 
> My position would be that one can be just as meaningful 
> as the other, depending on the context, and that the DPV
> protocol MUST be able to be used in contexts where the
> DPV request/response are (according to me) as good as 
> the certificates/crls/ocsp stuff.
> 

I guess this message chracterises perfectly what I have been
trying to explain.

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 10 Apr 2002 18:51:25 +0200 (MET DST)

> 
> But isn't it likely that the evaluation of the evidence happens
> at dispute-resolution time and is done not by the run-time 
> client but by some 3rd party? If not, then the client has to
> check everything at run-time; if so, then the fact that the
> client doesn't trust the relayed-to server is moot (what 
> matters is what the evidence evaluator thinks).

Yes, my interpretation is that the client trust HIS server to 
provide all evidences that MAY allow a potential/optional 
'evidence evaluator' to determine something *without* any 
need to access to some other hidden data. 

I did not say that the evidences MUST always be sufficient,
for example, as in real life they may degradable in time. 

> I would agree though that including just a dpv response as evidence
> might be misleading unless all relayed responses can be matched
> against the original request.

It seems that Denis think that only the OCSPresp, and CRLs that
are in a response need to be provided. One can also say that
time stamped versions of these data should be provided, then
well, a DPV response itself could contain a time stamp
of the data (e.g. CRL) etc. 

> Seems a bit confused to me (but then I'm often confused:-),
Wouldn't life otherwise life be much more boaring :-) 

Peter

---

From: Peter Williams <[email-masked]>
Date: Thu, 11 Apr 2002 10:00:53 -0700

Peter.

OCSP has always envisioned and practised a relying party
authorizing an OCSP Responder: no CA/AA involvement
is required and no certificate need be issued, in this
case.  

Carry over this conformance requirement from OCSP to DPV:

An OCSP client (which includes a client that is a DPV server)
must potentially accept an OCSP response according to ALL the 
rules of 4.2.2.2. There are three cases: (1) (2) and (3).

Lets remember, a relying party can operate its
own DPV service for its own benefit. The relying party 
needs no authority from a CA to do so. The operator
of a DPV server is not necessarily a TTP, and
need have no relationship to the cert or CRL 
issuer, other than that of performing
relying party obligations or (less stringent) user 
obligations according to the CP.

-----Original Message-----
From: Denis Pinkas
To: Peter Sylvester
Cc: [email-masked]
Sent: 4/11/02 3:18 AM
Subject: Re: Open issue: DPV relay

> See the second point and also read 4.2.2.2

Which says: 

   It is necessary however to ensure that the entity signing this 
   information is authorized to do so.  Therefore, a certificate's 
   issuer MUST either sign the OCSP responses itself or it MUST 
   explicitly designate this authority to another entity. 
 
> Or: You may want a requirement that the DPV responder must ensure
> that the OCSP responses are signed by a CA or an authorised responder
> and not by some locally trusted OCSP responder in order to
> be sure that an 'evidence verifier' finds trustworthy information.

This is correct. However, it is not necesssary to add this requirement
in
the DPV requirements document since this requirement is already in
section
4.2.2.2 from RFC 2560 (OCSP).

> > > To make the simple case, if a DPV response is signed directly by
the CA
> > > (or by an authorised responder), you have the same situation.
> >
> > No. A CA can only assert information about what it is directly
responsible.

> So, the DPV response made by the CA just talks about the certificates
> it has directly issued.

No. Talking about the certificates that a DPV server may have issued
does
not make sense. Certificates are only issued by CAs, AFAIK. Once again, 
a DPV server MUST answer for one (or more) certificates and must verify 
an entire chain of certificates, whoever has issued them. A DPV server
is 
*not* a CA. A DPV server can be *any* service provider. An organization
running a CA may also run a DPV server, in the same way as an
organization
running a CA may also provide a Time-Stamping service.
 
> > No CA is responsible for all the certifiactes from one path. An OCSP
query
> > is for ONE certificate, while a DPV query involves a CHAIN of
certificates.
> 
> The text says:
> 
>    The Delegated Path Validation (DPV) protocol allows a server to
>    validate one or more public key certificates according to a
validation
>    policy.
> 
>    In order to validate a certificate, a chain of multiple
certificates,
>    called a certification path, may be needed, comprising a
certificate
>    of the public key owner (the end entity) signed by one CA, and zero
or
>    more additional certificates of CAs signed by other CAs.
 
> In the simple case of only one CA, an OCSP response signed by the CA
> concerning the certificate in question does not say anything the
> validity of the CA cert since when it was signed with the same key.

> You thus just have on certificate.
 
> In a case of one intermediate CA, the DPV response may for example
> contain two OCSP responses, one signed by the intermediate CA
> concerning the revocation status of the end user and another
> concerning the statius of the intermediate CA signed by the
> top CA.
 
> If both CAs provide a DPV service instead of an OCSP service

You mean "If the organisation hosting a CA also provides a DPV service
... "

> in the same way, you have exactly the same situation except
> that this is a positive status information.
> 
> For example, the initial client asks for a combined status,
> it asks his own trusted service, this server asks the intermediate
> CA either to provide an OCSP status or a DPV status of the
> cert in question and then asks the top CA to provide a status of
> the intermediate CA's cert, and well, even three other OCSP
> responders to provide statement that the top level
> CA's cert is good.

I believe that you have mis-understood one idea behind DPV. DPV verifies
the
whole path processing. A DPV status about one intermediate certificate
of
the chain does not make sense. The validation policy is not about that
intermediate certificate but about a given certificate and a whole chain
above it. Applying the validation policy on an intermediate certificate
only
does not make sense.
 
> DPV would allow to combine the responses differently.
> It can well be that the intermediate CA/DPV responder
> itself asks for a DPV response from the top CA/DPV
> and include this in his DPV response to the initial server.
> 
> >
> > There are no similarities.
> "Ok, let's talk."
> 
> > > I think that there must be a language problem somewhere because I
> > > fail to see what *not* you are referring, i.e. to see where we are
> > > in disagreement.  I have not said that it is necessary for the
client
> > > to gather all information. I have said that the protocol must
provide
> > > a method to allow a client to ask and the server to respond with
that
> > > information.
> >
> > Maybe, since we possibly interpreted diffrently "what has
contributed to the
> > final decision".
> >
> > > > In case of a dispute, testing again the certificate validity,
means that
> > > > certificates, CRLs and OCSP responses must be available.
Anything else is
> > > > useless.
> >
> > > I think that this may be the core of our disagreement.
> >
> > > This is because you only accept that CA can create assertions
about the
> > > validity of their certificates using CRLs and OCSP.
> >
> > Correct.
> 
> Unfortunately we may be both wrong.
> 
> > > As soon as you would
> > > admit that some new protocol or service is provided that enhances
and in
> > > particular replaces them, the statements obtained via that service
are
> > > necessary.
> >
> > > I would like to know what you would have said 5 years ago when
only
> > > CRLs existed.
> >
> > Basicaly the chain must be verified and no element fom the chain
must be
> > revoked.
> >
> > Five years ago this information was provided off-line, i.e. via
CRLs. OCSP
> > allows to obtain the same information on-line. Between on-line and
off-line
> > I currently see no other mechanism.
 
> But you can have different protocols for these characteristics.
Offline
> you could use trees, online you can have DPV, 

No. On-line, to know the revocation status of a single certificate we
only
have OCSP. RFC 2560 states:

   It is necessary however to ensure that the entity signing this 
   information is authorized to do so.  Therefore, a certificate's 
   issuer MUST either sign the OCSP responses itself or it MUST 
   explicitly designate this authority to another entity.  

Note that this is true as well for CRLs. Either the CA signs the CRL
directly or designate another authority.

RFC 2459 RECOMMENDS for the support of the CRL distribution points
extension
which then contains a cRLIssuer field. "If the certificate issuer is not
the
CRL issuer, then the cRLIssuer field MUST be present and contain the
Name of
the CRL issuer. If the certificate issuer is also the CRL issuer, then
the
cRLIssuer field MUST be omitted ..." 

> or other techniques like
> timestamps over CRLs and OCSP responses to have a proof that the
server
> has provided the OCSPresp/CRL at a current date.

Time-stamping is not needed to prove that the server has provided the
OCSPresp/CRL at a current date. An OCSP response includes such a date.
CRL
checking uses thisUpdate and nextUpdate. Time-stamping may however be
useful
for other reasons. An informational RFC (i.e. RFC 3126 - Electronic
Signature Formats for long term electronic signatures) does however
indicate
such a format in the context of a signature policy. Another format could
be
derived from it in the context of a validation policy.
 
> > The basic question is whether first-hand information and second-hand
> > information should be used. In case of a dispute, only first-hand
> > information is useful (certificates and revocation status
information from
> > the CAs responsible for every certificate from the chain). DPV
responses
> > (i.e. the signed "yes" answers) are useless, unless the plaintiff
and the
> > defendant both trust the same DPV server.
 
> OCSP responses may also be useless, unless the plaintiff and the
> defendant both trust the same OCSP server.

Wrong. RFC 2560 sates:

   It is necessary however to ensure that the entity signing this 
   information is authorized to do so.  Therefore, a certificate's 
   issuer MUST either sign the OCSP responses itself or it MUST 
   explicitly designate this authority to another entity. 

In either of these cases, the plaintiff and the defendant cannot argue
that
the OCSP response is not valid (unless the OCSP responder has been
revoked
by the CA). They cannot argue that such responses are useless, or if
they
do, 
this argumentation will be rejected.

I have made my best efforts to explain all the rational behind DPV
responses,
which are very different from OCSP responses. I have also made my best
efforts to explain why in the general case a DPV response from a given
server is not necessarilly trusted by all clients, and thus would be
useless
in front of a court.

The security consideration section is very explicit on this issue:

"A DPV client must trust a DPV server to provide the correct answer. 
However, this does not mean that all DPV clients will trust the same 
DPV servers. While a positive answer might be sufficient for one DPV 
client, that same positive answer will not necessarily convince 
another DPV client."

Can we finally close this issue ?

Denis

---

From: Ambarish Malpani <[email-masked]>
Date: Fri, 12 Apr 2002 10:20:22 -0700

Hi Denis,
    This sounds good to me.

Regards,
Ambarish

> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Friday, April 12, 2002 7:46 AM
> To: pkix
> Thanks to numerous private e-mail exchanges with Stephen Farrell 
> (thanks Stephen !) we both came to an agreement on additional text 
> to address relaying, re-direction and multicasting.
> 
> So I submit this text to the list.
> 
> Denis
> 
> ====================================================================
> 
> 4.2. Relaying, re-direction and multicasting.
> 
> Protocols designed to conform to these requirements MAY include 
> optional fields and extensions to support relaying, re-direction or 
> multicasting features. DPV clients are NOT REQUIRED to support relay, 
> re-direct or multicast, therefore clients or servers which do not 
> support such features still conform to the basic set of requirements. 
> DPV servers are NOT REQUIRED either to support relay, re-direct or 
> multicast.
> 
> 1. Where relay or re-direct mechanisms are supported by a server 
>    a mechanism to detect loops or repetition SHOULD be supported.
> 
> 2. Where a DPV server chooses to re-direct the request to another
>    DPV server (i.e. chooses to provide a referral), a mechanism to 
>    provide information to be used for the re-direction SHOULD be 
>    supported. Note: In case where information to be used for the 
>    re-direction is sent back, clients are NOT REQUIRED to interpret 
>    that information (but MAY do so).
> 
> 3. These features MAY be supported by using additional parameters
>    in the request and/or response. Clients and servers that do not
>    support such additional parameters MUST still be able to use/offer
>    DPV service. In this way, implementers need not understand the 
>    semantics of any such extensions.
> 
> ====================================================================
>

---

From: "Trevor Freeman" <[email-masked]>
Date: Mon, 15 Apr 2002 13:47:22 -0700

Hi Tim,
I am in 100% agreement on assumption 1 and consider this one of the
cornerstones of DPV. Given assumption 1, I really don't care how many
servers do\do not support relay. We need a loop detection payload in a
request, but that is all. A client should have full confidence that all
it will get back from the DPV server is a yes or no answer. My biggest
compliant is around C. This is a critical difference between DPV and
LDAP referrals. It cannot simply return a referral because the client
may not trust the server referred to. If you go down the rat hole of
also returning a signed token to say if you trust me, you can also trust
him we should give ourselves a red card for client complexity. The whole
point of this work is that the client wants to say "I want a strait
yes\no answer to this question and don't bother me with details".
So no flammable comments here, just agreement.
Trevor

-----Original Message-----
From: Tim Polk [mailto:[email-masked]] 
Sent: Monday, April 15, 2002 1:08 PM
To: [email-masked]
Subject: RE: Open issue: DPV relay

Folks,

Here is my take on the relay/referral fracas, in two parts.

The first part addresses DPV relay includes (1) my assumptions about
DPV, 
(2) a little rationale, and (3) a proposed "solution" for DPV replay.
The 
second part amounts to four complaints about the impact of adding 
referrals, and my belief that it should not be supported.

                                                         Part 1: DPV
Relay 
Proposal

Assumption #1:

DPV relay is irrelevant to DPV clients.  They request answers from a 
trusted DPV server X, and server X MUST stand behind the response.
(That 
is, X can't say "I don't know, but Server Y says this certificate is 
okay."  It is up to X whether it can trust that answer.)

Assumption #2:

Many DPV servers will not relay requests.

Tim's Theory and what it is, too:

DPV servers that do not relay requests do not care if the request has
been 
relayed before they received it.  That only matters for loop 
detection/relay limits, etc.

DPV servers that do relay requests MUST be able to detect whether or not

the request has been previously relayed, and the request MUST have the 
complete list of servers that have received the request.

So, the conformance requirements:

Support for DPV relay is OPTIONAL for DPV servers.  DPV servers that do
not 
relay requests do not need to process or recognize the relay history 
information.

DPV servers that relay requests MUST satisfy all the following
conditions:
           (1) recognize and process relay history if present in a DPV
request;
           (2) able to generate a relay history including the complete
list 
of servers that have
           already forwarded this request; and
           (3) before relaying a request, the DPV server MUST verify
that 
the chosen DPV server
           has not already seen the message.  (That is loop detection 
occurs at the requester,
           not the recipient).

This proposal does not impact clients, it simplifies the most common DPV

servers, and it places *all* the burden on DPV servers that relay 
requests.  (As it should be, in my opinion.)

                                                      Part 2: DPV
Referrals

Complaint A

Referrals impact *all* DPV clients, significantly increasing their 
complexity.  Currently, the requirements indicate whether or not the
server 
could build a satisfactory path.  It seems to me that referrals force
all 
DPV clients to interpret a new class of answers: "I don't know but ask 
Server B".  (By itself, this isn't that compelling, I admit.  They get 
stronger, IMHO.)

Complaint B

One of the nice features of DPV is a single "proof" for archival.  This 
feature is broken by the introduction of DPV referrals.  Assume Alice is

trusts Server A, but she receives a referral indicating that Server A 
trusts Server B to validate this certificate.  Alice will need to
maintain 
both the referral from Server A and the answer from Server B.

Complaint C

Referrals for DPV are a very different animal than LDAP referrals.  Once

again, assume Alice is trusts Server A but she receives a referral 
indicating that Server A trusts Server B to validate this 
certificate.  Alice will need to authenticate the identity of Server B 
using information from Server A.  I think that means that Server A needs
to 
identify Server B by including Server B's public key in the referral.
If 
that is true, we just created a parallel key management infrastructure
and 
increased the complexity of our universe.

Complaint D

If LDAP is any indicator, nobody does referrals anyway.  Since DPV 
referrals will be significantly more complex, wouldn't it be better to
put 
the load on the server?

Alright, I'm off my soapbox.  Flame suit is zipped.  What do you all
think 
of these proposals?

Thanks,

Tim Polk

---

From: Tim Moses <[email-masked]>
Date: Mon, 15 Apr 2002 17:22:34 -0400

I'm hearing nothing but good sense.  All the best.  Tim.

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]]
Sent: Monday, April 15, 2002 4:47 PM
To: Tim Polk; [email-masked]
Subject: RE: Open issue: DPV relay

Hi Tim,

-----Original Message-----
From: Tim Polk [mailto:[email-masked]] 
Sent: Monday, April 15, 2002 1:08 PM
To: [email-masked]
Subject: RE: Open issue: DPV relay

Folks,

                                                         Part 1: DPV
Relay 
Proposal

Assumption #1:

Assumption #2:

                                                      Part 2: DPV
Referrals

Complaint A

Complaint B

Complaint C

Complaint D

Thanks,

Tim Polk

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 16 Apr 2002 13:42:34 +0200 (MET DST)

> 
> 
> Russ,
> 
> (modulo typos) I'm fine with this text.
> 
> Stephen.
> 
I second (or third, or forth or minute or hour) that.

I am glad that most my my requests (and some
others, too) concerning relaying seem to get some concensus.

There is still one left, currently stuck in a private
communication among Russ, Denis and me. 

Peter

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 16 Apr 2002 14:02:03 +0200 (MET DST)

Tom,

One question is: 'to prove vis-a-vis which entity':

A work flow component may just need a confirmation
of the companies internal work flow. If the
company needs to prove this vis-a-vis other
potential external entities, it sets up
a policy ccording to that to do: 

This may for example include a DPV service operated
by 'the other company' in order to prove that
'we have asked you (the other compnay), and your
compnay server asserted that the certificate
of person XYZ is useful to policy P, and we
have validated the status of your servers 
certificate at our commonly agreed CA validation
service.  

It is up to the 'local DPV service' to ensure to
which extend the answer can be considered more
or less globally binding. 

Peter S.

> 
>       Peter:
> 
>       If nobody disagrees with your statement about an RP providing its own
> DPV service, I think that you have provided the conclusive argument against
> using DPV responses in NR.  After all, in many NR scenarios the RP is
> trying to prove that his reliance on a signature was justified.  If the RP
> provides its own DPV service, the only answer to the question "why did you
> consider the signing certificate valid?" which it provides is "because I
> thought so at the time".  If you assume that single RP's rarely provide DPV
> in practice but that organizations which employ many RP's may do so, the
> answer is "because my employer thought so at the time".
>       This does not mean that DPV is not valuable, but it would mean that
> it (as opposed to DPD) is not useful for NR.
> 
>             Tom Gindin
> 
> 
> Peter Williams <[email-masked]>@mail.imc.org on 04/11/2002 01:00:53 PM
> 
> Sent by:    [email-masked]
> 
> 
> To:    "'Peter Sylvester '" <[email-masked]>
> cc:    "[email-masked] '" <[email-masked]>

---

From: "Tom Gindin" <[email-masked]>
Date: Tue, 16 Apr 2002 11:15:31 -0400

Denis:

      My point was that a DPV response was probably insufficient to support
certificate validation in NR.  Obviously, it doesn't imply signature
verification - but neither does an OCSP response.
      There is no reason for this issue to hold up sending DPV to the IESG,
since the majority of certificate validation does not have the same
requirements as NR.

            Tom Gindin

Denis Pinkas <[email-masked]> on 04/16/2002 09:32:29 AM

To:    Tom Gindin/Watson/IBM@IBMUS
cc:    "[email-masked] '" <[email-masked]>
Subject:    Re: Open issue: DPV relay

Tom,

> using DPV responses in NR.

The argumentation from Peter (William) has nothing to do with your
conclusion.

The question is different: can DPV be used for signature validation ?

The answer is the following:

A DPV response alone will be insufficient, so why there is a need for
signature validation.

This debate will NOT start before the DPV document is sent to the IESG for
last call.

Denis

> After all, in many NR scenarios the RP is
(snip)

---

From: "Tom Gindin" <[email-masked]>
Date: Tue, 16 Apr 2002 16:36:31 -0400

Peter:

      First, if you don't need an external party to validate the
certificate, you don't need to worry about any weaknesses in DPV.  Second,
unless you can prove that either a TTP or a party with closer links to the
signer than to the RP is the actual source of your DPV response, it
probably won't help much as evidence.

            Tom Gindin

Peter Sylvester <[email-masked]> on 04/16/2002 08:02:03 AM

To:    [email-masked], Tom Gindin/Watson/IBM@IBMUS
cc:    [email-masked], [email-masked]
Subject:    RE: Open issue: DPV relay

Tom,

Peter S.