Subject: DPD/DPV reqmts: hash of the request

From: Petra Barzin <[email-masked]>
Date: Sun, 03 Mar 2002 21:48:31 +0100

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: Peter Sylvester <[email-masked]>
Date: Mon, 4 Mar 2002 19:29:39 +0100 (MET)

Russ, Mike,

Some thoughts about what could be the meaning of
one or more requirements: 

- A response should contain sufficient information so that by
  looking to them either the original request or something
  equivalent could be determined.

- Given a set of few requests, and a response, it is
  easy to determine the request that corresponds to
  the request. 

- A response should contain sufficient information
  so that it is clear to what "kind of" request it
  refers to. 

Somewhat orthogonal: When does one need to detect this
'binding'. 

- Immediately after getting the response ?
 
- 5 years later ?

A probably really bad example would be that a DPV response 
to contain 'yes + CA certificate' 
but no indication of the EE certificate in question.

I think that the protocol should not prohibit too much
the preproduction of results.

Regards
Peter

> 
> Russ,
> 
> This also breaks pre-produced responses, a practice that can
> reduce latency.  Is this collateral effect intended?
> 
> Mike
> 
> > -----Original Message-----
> > From: Housley, Russ
> >
> > In my opinion, the requirement is to bind the
> > response back to the request.
> 
>

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 4 Mar 2002 14:21:45 -0500

Peter:

None of these seem particularly onerous.  However, I am not sure where you
would like to see them incorporated into the document.  Please propose
specific changes.

Russ

-----Original Message-----
From: Peter Sylvester
To: Housley, Russ; [email-masked]
Cc: [email-masked]
Sent: 3/4/02 1:29 PM
Subject: RE: DPD/DPV reqmts: hash of the request

Russ, Mike,

 
- 5 years later ?

Regards
Peter

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 5 Mar 2002 16:51:57 +0100 (MET)

Russ and Mike,

If the following text for DPV requirements looks 
basically acceptable concerning the bindings
of a request to a response, feel free to correct
my English or whatever. 

Thanks in advance
Peter

- The protocol MUST provide a means permitting a client
  to associate a response to a request. This MAY be achieved
  either by using transport layer mechanisms, or by
  payload information.

- There MUST be a method to allow a client to force a
  specifique response, e.g. by using a nonce. Note, that
  this does not mean that information cannot be cached. 

- If a response contains a binding to some other information,
  e.g. to the original request, the techniques used should
  provide for long term stability, e.g., explicit copying
  of some information, in particular, a response MUST contain
  sufficient information in order to determine what certificate
  path validation had been requested.

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 7 Mar 2002 15:13:30 +0100 (MET)

> 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?
No. a server always has an implemention and MUST react on
whatever the client desires (or not, if policy does not allow this).

> 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
Your concern probably does not apply for this particular case, 
but rather to another set of policy related request that a server
may make, if the protocol allows to add almost arbitrary indications
defined by a completely open set of OIDs for example of what a
client can request.

> 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.
The requirement is to mandate a correct reaction if used by a client.
Indeed, as already said, one can preproduce some information but
maybe not the complete response.

Peter