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

From: Peter Sylvester <[email-masked]>
Date: Tue, 26 Feb 2002 17:25:08 +0100 (MET)

> 
> Good question !
> 
> 
> However, you don't propose a solution.
You were supposed to answer my question. 

> 
> One way to fix the problem would be to say:
> 
>    3) the server cannot determine the validity of the certificate.
>       This condition will occur when a certification path cannot be
>       constructed.
This is as unclear as before, is this a temporary or a permanent condition.

If it is a permanent condition, then the certificat is invalid.

> 
> In fact what is important for an application is:
> 
> a) valid,
> b) (definitively) invalid; no need to try later, it will remain invalid,
> c) (temporarily) invalid; if you tried later, then it could be valid,
> d) no idea whether it is valid, definitively invalid or temporarily invalid: 
>    there is not enough information currently available to determine.
> 

Do I agree with Mike by saying the following?

1 - a cert is valid according a policy
2 - it is invalid
3 - you have a temporary service error because of a dos or two planes.

The service gives details about why a cert is invalid/valid.

regards
Peter

May I remind You to consider to respond with 1, 2, 3 to the requirement 
validation requests that I have send yesterday. Thanks in advance.

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 28 Feb 2002 16:37:50 +0100

Petra and Peter,

Please find below responses to your comments.

COMMENTS FROM PETRA BARZIN

I would like to propose some more requirements to be included
in the DPV/DPD requirements draft:

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

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

[COMMENT 3]

- add one more component to a validation policy: algorithm requirements
They identify the minimum key length of the signature key or
untrusted hash- and signature algorithms.

[Answer 3] I guess that you mean requirements only for the public key
contained in the end-entity certificate to be validated. I am not sure that
this is relevant. If you trust the certificate policy under which the
end-entity certificate has been issued, then you trust the CA to certify
public keys that have the right algorithm and key length. So I believe that
your concern is already solved by specifying certificate policies.

[COMMENT 4]

- add another request/response pair to obtain the definition of a
specific, the default or all validation policies defined on the server.
So far only the references of a validation policies can be returned.
But it might be necessary to retrieve the definition of a validation policy,
too (e.g. for archiving).

[Answer 4] You did not say where you wanted this addition. The server may
support validation policies that have been locally set up, so there may not
be a formal definition that matches the policy. So at least for these one,
this will be impossible. I would like the current request/response pair to
be usable,
without the need to support the request/response pair allowing a remote
definition of the policy. So I would keep the section 6 unchanged.

However, supporting this as part of section 7 - PDP (Policy Definition
Protocol) can certainly be considered.

COMMENTS FROM PETER SYLVESTER

There are some comments for DPV that have been ignored.

The last three blocks in chapter 4 talk about security
requirements, but the following two are not mentioned
(unless I miss something).

- Security requirements

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

[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.
No change is necessary.

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

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

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

Regards,

Denis

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 Feb 2002 16:54:24 +0000

Denis,

>   important elements from the request must be present.

I'd love to know why this is the case, given that signing involves
hashing and use of a private key. Is a 2nd hash a bad thing or
something? (Note: I agree that a protocol could follow this rule,
but copying should not be a requirement on a protocol).

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