Subject: RE: DPD/DPV reqmts: hash of the request

From: Peter Williams <[email-masked]>
Date: Wed, 06 Mar 2002 14:42:37 -0800

Can you state a rationale why DPV/DPD
design on the issue should be different to the 
OCSP design on the same issue? 

OCSP supports pre-calculated OCSP responses,
based on OCSP relaying certificate status information
from a repository.

Why should DPV not support pre-calculation
of one or more sets of validation policy rules against
a chain of certificates?

Is there a basis for believing that DPV protocol 
is more vulnerable that OCSP protocol in respect
of the known risks of using pre-calculated (i.e. cached)
results?

Accessing a historical repository of DPV results
will be quite common, I expectm in support of NR. 
Periodically,
the operator will calculate for a large
number of certificates with historical
certificate status what the validation policy
would have been, if evaluated at that historical
point in time. 

-----Original Message-----
From: Petra Barzin [mailto:[email-masked]]
Sent: Wednesday, March 06, 2002 1:37 PM
To: Michael Myers
Cc: Housley, Russ; [email-masked]; [email-masked]
Subject: Re: DPD/DPV reqmts: hash of the request

Mike,

do I understand you correctly, that you propose to mark the
requirement (binding the response back to the request) as
optional and leave it up to the implementation of the DPV
client and server to realize this binding?
I'm afraid this will lead to unnecessary interoperability problems
between implementations of a DPV client and server, e.g. if a
client implementation requires this binding, but it's not implemented
at the server. If we feel that the binding adds value to the protocol
- and I think it does - we should mandate its use! You can still
cache the information and re-use them, you just cannot preproduce
the whole response.

Petra

Michael Myers schrieb:

> Petra,
>
> In my opinion we should enable the practice by ensuring the
> capability is in running code but not mandate its use in all
> circumstances.  Do you find this approach acceptable?
>
> Mike
>
> > -----Original Message-----
> > From: Petra Barzin [mailto:[email-masked]]
> > Sent: Tuesday, March 05, 2002 12:17 PM
> > To: Housley, Russ
> > Cc: [email-masked] '; [email-masked] ';
> > [email-masked]
> > Subject: Re: DPD/DPV reqmts: hash of the request
> >
> >
> > Yes, the requirement is to bind the response back to
> > the request!
> > Sorry for the technical discussion at this point.
> > I'd see the requirement as a MUST, but I can see
> > Michael's concern
> > that it prevents the use of pre-produced responses.
> > But I think it is very important that the sender of a
> > DPV request
> > is able to match the received response to his request
> > in order to
> > make sure that no man in the middle changed his
> > validation request.
> >
> > - Petra
> >
> > "Housley, Russ" schrieb:
> >
> > > In my opinion, the requirement is to bind the
> > respponse back to the request.
> > > Two obvious was to accomplish this binding are to
> > include all of the fields
> > > of the request in the response and to include a
> > hash of the request in the
> > > response.  Since we are working on the requirements
> > doucment, we should
> > > stict to requirements, not mechanisms for
> > implementing the requirements.
> > >
> > > Russ
> > >
> > > -----Original Message-----
> > > From: Petra Barzin
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Sent: 3/3/02 3:48 PM
> > > Subject: DPD/DPV reqmts: hash of the request
> > >
> > > Denis,
> > >
> > > I don't see why you differentiate between signed
> > and authenticated
> > > responses. The same is true for signed responses:
> > either the hash of
> > > the request or the important elements from the
> > request must be present.
> > > In order to test the response against what has been
> > requested the client
> > >
> > > has to keep his request or at least the hash of his request.
> > >
> > > The advantage of a hash - instead of copying all
> > important elements
> > > from the request -  is:
> > > (a) that the response will be smaller and
> > > (b) adding a new important element to the request
> > doesn't require a
> > > change of the response.
> > >
> > > - a hash of the request MUST be included in the response.
> > >
> > >   This may allow the client to check if his request
> > was maliciously
> > >
> > >   modified (if the response is signed) and helps to
> > associate the
> > >
> > >   response with his request when using
> > connectionless protocols.
> > >
> > >   [Answer 1] The requirements are different whether
> > the requester simply
> > > wants
> > >
> > >   an authenticated response or a signed response.
> > For a signed response
> > > the
> > >
> > >   inclusion of the important elements from the
> > request is needed, so
> > > that a
> > >
> > >   response can be individually tested against what
> > has been requested.
> > > For an
> > >
> > >   authenticated response, the hash of the request
> > is sufficient. To
> > > summarize:
> > >
> > >   - for signed responses, the important elements
> > from the request
> > >
> > >     must be present.
> > >
> > >   - for authenticated responses, either the hash of
> > the request or the
> > >
> > >     important elements from the request must be present.
> > >
> > > - Petra
> >
> >

---

From: Petra Barzin <[email-masked]>
Date: Mon, 18 Mar 2002 09:20:46 +0100

Peter,

as far as I know, OCSP doesn't support the hash of the request in its

responses but it uses nonces to bind the response back to the request.

The use of nonces is up to the client but if the client includes a
nonce

in his request the server CANNOT use pre-calculated OCSP responses!

Quotation of OCSP:

If a nonce is included in a request, then the
response MUST contain the same nonce. Responses
without the same nonce MUST NOT be trusted.

Of course, most of the content of an OCSP answer (except of the
nonce)

can be pre-calculated. But the same is true for DPD/DPV. You can

cache validation results and re-use this information. But you cannot

pre-produce the whole answer. So it's exactly the same as with OCSP!

Petra

Peter Williams schrieb:

from a repository.

a chain of certificates?

results?

Periodically,

point in time.

-----Original Message-----

To: Michael Myers

Mike,

the whole response.

Petra