Subject: RE: Open issue: DPV relay

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

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]>
Subject:    RE: Open issue: DPV relay

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

> Peter

---

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

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