Subject: Re: Open issue: DPV relay

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

> 
> I agree that there is a difference between an authorized responder 
> and a server trusted under a given policy. 
> 
> So in order to solve this last issue, I propose to replace the current text
> which is:

The reason why I discussed this was to explain that regarding trust
issues there is no fundamental difference between a DPV responder
and an OCSP responder. 

As we see, OCSP responders come in two flavors, either they
are authorised by the CA (respses signed by the CA or 
an athorised responder), or are locally trusted. 

I do not see why DPV responders are essentially different: It
may be that there are *more* DPV responders that are locally trusted
but I do not see why a CA cannot sign DPV responses for all its
client certs or designate a responders in exactly the same way
as for OCSP.

Denis mentioned that a DPV responder indicates the validity of
a path: I slightly disagree: If one does not return the path
and no other information, the DPV responder only indicates the
validity of the cert according to a policy, like OCSP indicates
the "invalidity status".  
 
Even, assumung that DPV indicates the validity of a path, I
do not see why it creates harm to include such responses in
DPV responses. 

For example, a DPV responder that would return OCSP status info for
all certs in the chain (except the top one?) could just return
one DPV response of the first CA chain. 

Denis replied to Peter;
> > 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.
It = the CA. 

> 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. 
No, I claim taht the only thing a DPV server MUST tell is whether the cert is
valid against a validation policy, everything else is optional. 

> 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.
The agument was, whether this is different to OCSP. It is *NOT* as we 
all just found out. An OCSP respoinder can be *any* service provider. 

Denis said:
> > 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 ... "
I won't tell you whether you attempt to make a telepathic intrusion
test was successful or not. :-)

Denis said: 
> 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.
Thank you for reminding me: 

The rationale paragraph 2 says:

     DPV allows a server to perform a real time certificate validation for 
     a validation time T, where T may be the current time or a time in the 
     recent past.
no word about PATH. The next paragraph says

     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.
"may be needed"

The next paragraphs talk about path validation, BUT: The server is allowed
to return a good/bad answer without giving any information about the path
used, and trusted roots as input are optional. 

But anyway: Where did I say that the same validation policy MUST be used
to validate an intermediate certificates. The question is only that
the actual texts prohibits any other information to be returned. 
 
> > 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:

RFC 3029 for example also provides a service to provide certificate status. 
 
But your argumentation is completely unacceptable for another reason. 
You are completely ignoring that one can make progress in the future. 
It is like the people about 100 years ago that argued that the only way 
to solve a dangerous problem of horse shit on streets was to create more 
services to remove it (completely igoring the arivale of cars .. which created 
other problems, but that's another story). 

You require that nothing else than OCSP responses and CRL MUST be returned.
never, ever. 

IN the following you mention thet time stamps *MAY* be useful for
*other reasons*. Thus, it may be useful to create a time stamp
of the OCSP responses and CRL responses in order to indicate when
the information have been verified. This is just one example of
why other and different information could be returned by a DPV responder.
This information may not dbe directly destined to the DPV client but
to some other relying party. 

> > OCSP responses may also be useless, unless the plaintiff and the
> > defendant both trust the same OCSP server.

> Wrong. RFC 2560 sates:
I think it is not necessary to repeat why the argumentation that follows
is wrong, in particular the following sentence is true as well for OCSP: 

  "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."

> The DPV request MUST allow the client to request that the response 
> include the certification path and revocation status information used 
> by the DPV server to process the request. When requested, the DPV 
> server MUST include the certification path and revocation status 
> information in the response when the certificate is valid according to 
> the validation policy. However, the server MAY omit the certification 
> path and revocation status information when the certificate is invalid.
> 
> by the following text:
> 
> The DPV request MUST allow the client to request the response to 
> include either the certification path and the revocation status 
> information from authorised CRL issuers or authorised OCSP responders, 
> or a DPV response from a DPV server that is trusted under the 
> validation policy. This information may allow other clients, not 
> trusting the requested DPV server to be confident that the certificate 
> validation has correctly be performed. When the certificate is valid 
> according to the validation policy, the server MUST, upon request, 
> include that information in the response. However, the server MAY 
> omit that information when the certificate is invalid or when it 
> cannot determine the validity.

You are turning around a  necessary and sufficient  property: 
Requiring *authorised* issuers may not be necessary in some
circumstances, e.g., when the relying parties are a known
group that trust the same responders. 

To summarize: I just repeat my request that : 

' A DPV responder may return additional information concerning the
  status of the certificate in question, such a the selected
  certification paths, OCSP responses, CRL responses and other
  information about the validity of the certificate, or parts
  of the parts. etc., examples are DPV responses, time stamps, .. 
  which are necessary in order to allow relying parties
  (not necessarily the initial DPV client) to determine the
  status of the certificate. '

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 16 Apr 2002 15:26:40 +0200

Peter,

I changed the name of this thread, since this is not related to DPV relay,
but to DPV additional information.

Foreword: If you want to save time you can go directly to the end of this
(too long) e-mail.

> issues there is no fundamental difference between a DPV responder

There is. See below.
 
> an athorised responder), or are locally trusted.

No. DPV servers are never authorized by CAs. They are either :

 - locally trusted by their requesting clients for any policy, or/and
 - trusted under a given validation policy.

> client certs or designate a responders in exactly the same way

A CA cannot sign DPV responses.

> the "invalidity status".

Not exactly, but the "revocation status from a single certificate".
 
> do not see why it creates harm to include such responses in

The DPV response may include *in addition* to the validity status, 
all the information that yield to prove that this validity. 

> one DPV response of the first CA chain.

A DPV server is a function that shall *not* be confused with the function 
from another server, like an OCSP server.

> valid against a validation policy, everything else is optional.

The argument from your last sentence is correct and does not contradict my
sentences. So it does not explain the "No" placed in front.

> all just found out. 

As mentioned earlier, OCSP responders come in two flavors: 

 - either they are authorised by the CA, 
 - or are locally trusted.

DPV servers are either :

 - locally trusted by their requesting clients for any policy, or/and
 - trusted under a given validation policy.

> An OCSP respoinder can be *any* service provider.

> the actual texts prohibits any other information to be returned.

Wrong. There is text to support other information, in particular a DPV
response. A proposal to improve that text was included in that same e-mail. 

> You require that nothing else than OCSP responses and CRL MUST be returned.

Next time, please read the whole e-mail before responding or posting. 
Your assertion is incorrect. See the end of the e-mail you responded to.

> to some other relying party.

Correct.

> group that trust the same responders.

How can it be known the relying parties are a known group that trust the
same responder ?

Since a DPV responder can support multiple validation policies, this notion
depends from the validation policy and the validation policy may thus
include the set of trusted DPV responders under that policy. This set may be
different from one policy to another.

This means that the valid response may include in addition to the response
from the *locally* trusted DPV server the response from a *policy* trusted
DPV server. This is exactly what the text above was attempting to say.

>   status of the certificate. '

We are not that far. A DPV response was already present in the text.
Time-stamp tokens can be added:

I would propose the following :

The DPV request MUST allow the client to request the server to include 
in its response additional information which will allow relying parties 
not trusting the requested DPV server to be confident that the 
certificate validation has correctly been performed. Such information 
may consist of a certification path, revocation status 
information from authorised CRL issuers or authorised OCSP responders, 
time-stamp tokens, or a DPV response from a DPV server that is trusted 
under the validation policy.  When the certificate is valid according 
to the validation policy, the server MUST, upon request, include that 
information in the response. However, the server MAY omit that 
information when the certificate is invalid or when it cannot determine 
the validity.

Denis

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 16 Apr 2002 08:22:52 -0700

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Denis Pinkas
>
> . . .
>
> . . .

Denis,

A while back I quite carefully parsed the -03 version of the I-D
into requirements statements.  Nowhere did I see these negative
requirements asserted.  Had they been there, I'm quite certain I
would've raised an issue on the list.  Do you really mean to say
that a CA can neither directly affirm the validity of its own
certificates nor delegate that obvious right to another party?

Mike

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 17 Apr 2002 11:42:12 +0200

Michael,

The text you mention is *not* going to be placed in the requirement
document, but was only explanations.

Since there has been many small changes since version 03, I will re-issue
a draft shortly so that everybody can see the result of the more than 
* 300 e-mails * that have been exchanged.

Denis

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 17 Apr 2002 07:00:33 -0700

Denis,

Even as explanations, I disagree with the assertions.

A CA can most certainly sign DPV responses, especially relating
to its own certificates.  A CA can also delegate that function
(i.e. authorize a DPV server) to another trusted party.  That
party could conceivably itself be a CA.  Thus a CA can sign DPV
responses even with respect to certificates it didn't issue.

In my view, these are deployment and operational issues relating
to specific policies, practices and perhaps even contracts, all
of which seem to be well out of scope of our technical
considerations.  But maybe that's just me.

Mike

> Sent: Wednesday, April 17, 2002 2:42 AM
> To: Michael Myers
> Cc: pkix
> Subject: Re: Open issue: DPV additional information
>
>
>
> Michael,
>

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 17 Apr 2002 16:10:11 +0200

Michael,

> responses even with respect to certificates it didn't issue.

I respectfully disagree with you.

The concept and the functions of a CA and of a DPV server are not related.

There is no notion of "designated DPV responder" by a CA and we are not
going to define new certificate formats for that purpose.

Denis

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Apr 2002 15:47:54 +0100

Denis,

> The concept and the functions of a CA and of a DPV server are not related.

What's the benefit of being (IMO) as pedantic as this?

Most people are happy enough for the term CA to mean either
the system that does X.509 things or the authority that 
runs that system (and can therefore also be properly said
to be doing things like DPV).

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: Wed, 17 Apr 2002 17:02:14 +0200

Stephen,

> Extract from the road map document:

   Certification Authority (CA) - An authority trusted by one or 
   more users to create and assign public key certificates. 
   Optionally the CA may create the user's keys. It is important to 
   note that the CA is responsible for the public key certificates 
   during their whole lifetime, not just for issuing them. 

Denis

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 17 Apr 2002 08:22:12 -0700

Denis,

It is precisely that issue of responsibility, in a broader
sense.  I'm quite certain that organizational entities who
create, issue and maintain the reliability of public key
certificates will will be the first to claim jursidiction
regarding their validity. Who is going to claim otherwise?

Mike

> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Wednesday, April 17, 2002 8:02 AM
> Certification Authority (CA) - An authority
> trusted by one or more users to create and assign
> public key certificates. Optionally the CA may
> create the user's keys. It is important to
> note that the CA is responsible for the public key
                      ^^^^^^^^^^^^^^^
> certificates during their whole lifetime, not just
> for issuing them.

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 25 Apr 2002 15:10:31 +0200

Michael,

> regarding their validity. Who is going to claim otherwise?

Let me provide you with an example:

Avis Rent a Car (TM) is wishing to accept tourist car reservations using
public key certificates in France. Avis Rent a Car (TM) will define the 
"Avis Rent a Car (TM) reservation policy in France for tourism vehicules" 
and state that under this policy Microsoft certificates class X, Verisign
Certificates Class Y and Debis certificates Class Z are adequate. Microsoft,
Verisign and Debis as CAs, are fully ignorant which applications are making
use of their certificates.

There needs not be any relationship between validation policy issuers and
CAs.

Validation policy issuers will pick up in their validation policies which
CAs are appropriate.

Denis

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 25 Apr 2002 08:45:30 -0700

Denis,

In that scenario there are really two questions.  First, is the
certificate valid in the sense that it is reliable and the
circumstances relating to its issuance haven't changed in any
material way.  Having determined that, the next question is
"acceptable for a given purpose"?  Clearly the latter case is
more in scope of your rental car company.

However, your rental car company is then a relying party to the
issuer of those certificates it chooses to accept and thus
subject to any relying party agreement those CAs may have in
force at the time.  Maybe none such exists, but it's still a
relying party (at least as far as this technologist understands
the concept).

So I think it's dangerous to promulgate a notion that would lead
folks to believe that a certificate can be unilaterally asserted
as "valid" without any reference or relationship whatsoever to
the party that originally issued the certificate (where "valid"
has, or soon will have, a precise technical meaning in this WG).

What I hear you saying is, "acceptable for a given purpose"
which assertion can certainly lie beyond the scope of a CA.  One
that basis I agree with you.  Note, however, that if your rental
car company parses a cert looking for CA identity or equivalent,
and tosses it because it's not in the acceptable set without
ever bothering to run a path check (which design approach seems
likely), it's better to send back "unknown" rather than
"invalid". Better yet perhaps, an unsigned error. I suspect the
certificate's issuer may take offense at other parties claiming
its certificates are invalid when in point of fact they're not.

As Hal said, we've probably kicked this one to death but I just
wanted to raise that little flag of caution regarding the
relying party concept now that I better understand your
position.

Mike

> Sent: Thursday, April 25, 2002 6:11 AM
> To: Michael Myers
> Cc: [email-masked]; pkix