Subject: Re: "Potentially valid" response state in DPV/DPD rqmts I-D

From: Peter Sylvester <[email-masked]>
Date: Thu, 28 Feb 2002 17:44:02 +0100 (MET)

Thanks for the response. 

> 
> [COMMENT 1]
> 
> - 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.

This is describing a particular solution of the requirement. I think I 
agree with the description of Ambarish: 
    "At the most all you
     should require in this document is that there be a way to show
     that a response corresponds to a particular request. Whether this
     is done by copying the request in the response, or just including
     its hash is the protocol designers prerogative."

> [COMMENT 2]
> 
> - a random number MAY be included in the request.
> This allows replay protection when the client has no clock.
> The random number doesn't have to be repeated in the response
> if the response contains a hash of the request.
> 
> [Answer 2] Replay protection is so obvious that it has been omitted. We
> could certainly add some text. The nonce cryptographically binds a request
> and a response to prevent replay attacks. However when you say: "The random
> number doesn't have to be repeated in the response *if* the response
> contains a hash of the request". This sentence is in contradiction with your
> first comment where you say: "a hash of the request MUST be included in the
> response". A choice needs to me made.  :-)
> 
> I believe that the nonce should be in the response as well, just because it
> is easier for the client to compute the hash over all the fields from the
> response instead of saying: "after the item X, I need to copy the nonce from
> the request".

Ambarish's remark can be adapted to this case: "In some cases, it may be
necessary that some explicit mecanism for replay mecanism is necessary,
a protocol should provide for such a means. This can be done for example by
exchanging random nonce values". 

> 
> COMMENTS FROM PETER SYLVESTER
> 
> 
> [COMMENT 5]
> 
> - a method to authenticate a server before sending any request
>    (for example this can be achieved by SSL).
>    (Another example would be using encryption.)
> 
> [Answer 5]. This is covered under the following wording: "In order to be
> able to be confident that the validation of the certificate has correctly
> been done, the client only requires an authenticated response". No change is
> necessary.

This statement covers authentication of a response, I am asking for
authentication of the service before sending a request. Regarding
your response to the next comment, yes, this can be implemented by
a transport mecanism, but there is still a requirement. 

> 
> 
> [COMMENT 6]
> 
> - a method to ensure confidentiality of the transport.
> 
> [Answer 6] There is nothing here in that protocol that mandates
> confidentiality like protecting the value of a private key or a secret key.
> The transport can provide confidentiality in support of environments that do
> not wish to reveal requests or responses contents, e.g. using TLS or S/MIME.

Basically You agree that there is a requirement for confidentiality. Whether
it can be supported by a transport mecanism is a solution. 

> No change is necessary.
I Disagree.

> 
> 
> [COMMENT 7]
> 
> - a method that client and server provide their identity
>    in the requests and responses: 'You, the client X, has
>    asked me, the server Y, the following question, and
>    I, the server Y, with the help of server Z respond.'
> 
> This allows to be able to determine the participating entities
> without having access to whatever particular authentication
> method information.
> 
> [Answer 7] Actually, we already include the identity of the server in the
> response. The request could also be optionally signed. This allows 
> the server to authenticate the client, and this authentication allows the 
> server to only support a selective community if desired. An option to be
> able to sign the request may be added.
> 
> The following requirements may be used for example in case of
> validation of an encryption certificate before usage.

There is a difference between authentication and identification.
The request is that the identification is independant from the
authentication methods and the transports. 

A signing entity (the one identified in a signerinfo or a certificate)
may or may not be the same as the one declared in the request/response.
you may have separation of roles or other situations. 

"The President of the United States declares, ... signed by JWB".

Another example is in relaying as follows: 

Your company service delares that I can use Your encrytion cert,
and the response is signed by my local service. 

> 
> 
> [COMMENT 8]
> 
> One may resume the relaying requirements into one:
> 
> - The protocol MUST provide a means to allow (visible) relaying
>    of requests and responses.
> 
> - Relaying requirements:
> 
> - depending on policy, a server may just impersonate another
>    server, i.e., take the responses of another server, and create
>    its own response out of them.
> 
> - a server should be able to include the response of a relayed
>    server into his response.
> 
> - a server should be able to simple add another authentication
>    scheme to a response from another server (for example by
>    using a second signature or a counter signature.)
> 
> - a server that acts as a relay should be able to tell to the
>    next server that it is acting on behalf of a end user, and
>    the final server should be able to note this in the response.
> 
> - For relaying, the protocol MUST provide an efficient means
>    to detect loops.
> 
> [Answer 8] Clients trust some dedicated servers. They don't care how the
> information that is provided has been established: there is a single server
> that is responsible: the one which provides the answer. If the response is
> signed by the expected private key, then it is acceptable, otherwise it is
> not. There are not requirements for chaining or referral services. Relaying
> between
> servers is not the topic of this document. No change is necessary.

There is already a requirement that a service returns all information obtained
from other services. There may be OCSP responses, crls, etc. Relaying of one
request (for example of an encryption certificate before its usage) to 
another DPV service seems a possible implementation. 

If I would follow Your logic, then the DPV server never needs to return
anything else than a authenticable YES/NO/DONTKNOW. 

There are requirements for relaying etc. 

> [COMMENT 9]
> 
> - Requirements for incomplete answers:
> 
> - a server may indicate an incomplete response,
>    and provide a method to update the response later.
> 
> [Answer 9] This would create the maintenance of state information which
> should be avoided. There has been plenty of discussion on the list regarding
> the number of states.  People clearly want the fewest possible number. The
> client may query again later on. No change is necessary.

You are accepting the requirement as such but You propose not to 
include it in the document because of some implementation detail. 

You always have state in a server (maintaing a TCP connection for example.)

The fact that this requirement requires some particular feature in
an implementation does not mean that the requirement doesn't exist.

It does neither mean that a particular implementation of the protocol
MUST implement for example given a first online response and sending
a later mail. 

Peter