DPD/DPV reqmts

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

To the list,

You will find hereafter additional responses to the comments raised during
the WG last call. In any case for further discussions, please indicate first
the comment number. This was not done by Petra and thus does not make the
task easy. Also do not use separate e-mails.

[About COMMENT 1]

>From Petra Barzin <barzin@xxxxxxxxxx>

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.

[Additional Answer 1]

Two answers:

1) Signed answer may be individually re-verified, while authenticated
answers may depend on a context that cannot necessarily be reconstructed
later on. If signed answers are used for authenticated responses, then there
is no more difference, but here we indicate requirements, not solutions.

2) The most important is to be able to use a signed response alone. If the
signed response only contains the hash of the request, then the request must
also be kept to know what the question was. A format for concatenating the
request with the signed response would then be necessary.

So, contradictory to what Peter(Sylvester) said, copying the request in the
response, or just including its hash is not a protocol designers
prerogative.


[About COMMENT 2]

yes, indeed. There is a contradiction. My last sentence should be:
The random number doesn't have to be repeated in the response
*because* the response contains a hash of the request.

I don't understand your last comment. The client does not compute
the hash over all the fields from the response but from his request!

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

[Additional Answer 2]

At this time we have not agreed to always include the hash of the request.
So if the hash is not there, then the random number must be there. See also
the argumentation about comment 1 above.


>From Peter Sylvester

Most of the previous responses have been prepared collaboratively by the two
co-editors: Russ and myself. Therefor, I would kindly ask to Peter Sylvester
to avoid to use "you", in particular with a capital Y in words like "You" or
"Your".

[About 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 mechanism, but there is still a requirement. 

[Additional Answer 5]

Authentication of the service before sending a request is not performed in
similar protocols like OCSP. There is no particular reason to do so for this
protocol.

[About 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 mechanism is a solution. 

> No change is necessary.

I Disagree.

[Additional Answer 6]

There is no requirement on the protocol to support confidentiality. In the
same way OCSP does not support confidentiality at the level of the protocol,
but can support it at the transport level.

[About 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 signer info 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 declares that I can use Your encryption cert,
and the response is signed by my local service. 

[Additional Answer 7]

It is unclear what requirement is being addressed and what kind of treatment
would be done with such an identity field.


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

[Additional Answer 8]

There are no requirement for relying nor referrals. We are not going to jump
into the complexity of protocols like DAP(Directory Access Protocol). Note
also that in addition to the YES/NO/DONTKNOW authenticable answer, the path
elements may be returned.


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

[Additional Answer 9]

As already said, there has been plenty of discussion on the list regarding
the number of states.  People clearly want the fewest possible number.


From: Yuriy Dzambasow" <yuriy@xxxxxxxxxxxx>

Some additional comments.  I have separated them into the following
categories: editorial and technical.

Editorial (at least I am assuming these are editorial):

[COMMENT 19]

1) Recommend deleting the 2nd paragraph on page 5 (Section 5) for the
following reasons:
        - the first sentence attempts to qualify the preceding paragraph,
and in my
opinion, adds no additional value
        - the second sentence contains redundant information already defined
two
paragraphs above

[Answer 19]

The second paragraph on page 5 (Section 5) is:

Clients MUST be able to specify whether they want, in addition to the 
certification path, the revocation information associated with the 
path, for the end-entity certificate only, for the CA certificates 
only or for both.

This text is not redundant. You are certainly pointing to another paragraph.
Next time, please provide a short extract.

[COMMENT 20]

2) In section 5, 3rd paragraph it says, "...In that case it is acceptable to
pass the parameters from the path discovery policy with each individual
request, i.e. a set of trust anchors..."  Please change the "i.e." to "e.g."

[Answer 20]

OK.

[COMMENT 21]

3) Section 8, first paragraph: The text states that a client can use a
request/response pair to define to a server a "..validation policy and/or a
path discovery policy..."  Please change "and/or" to "or".

[Answer 21]

OK.

[COMMENT 22]

4) Change title of 8.1.1 to Certification Path Requirements, so that it is
consistent with the text in section 8.1, item 1.

[Answer 22]

OK.

Technical:

Most of my comments have been addressed (or are being addressed on previous
threads).  I have these three additional comments:

[COMMENT 23]

1) Why does DPD say that it is OK to pass some policy parameters within a
DPD request if the policy is simple enough (section 5), but just the
opposite is said for DPV (section 4)?  I would think that a simple policy
could be adhered to as well for DPV, and that the parameter specification
could occur within the DPV request.

[Answer 23]

The document does not provide details about what means "simple". However the
idea is the following: when there is a single root, with no constraints
(unless contained in the self-signed certificate itself) and when any CRL
status information is acceptable, then the policy can be considered as
simple. Specific checks on the end-certificate are always done locally.

With DPV the policy has to say which CRL information is necessary for each
leg. But the most important is that checks on the end-certificate have to be
done remotely and specifying them is that not simple.

[COMMENT 24]

2) For DPD responses (page 5), why do the first three response types say,
"...according to the path discovery policy...", while the last response type
says, "...according to the path discovery criteria..."?  What is the
difference between policy and criteria?  If there is no difference, then I
recommend changing "criteria" to "policy".

[Answer 24]

OK.

[COMMENT 25]

3) Section 8:  I think it would be helpful to break out the PDP requirements
section into two areas: 

1) requirements around the coordination of a validation/path discovery
policy
between a client and a server to support the validation/path discovery for 
a given certificate; and 

2) requirements around defining an authorized policy at a server (e.g., used 
by security managers).  

This makes it clear that PDP can be used in two distinct ways.

[Answer 25]

PDP only addresses the later. It is unclear what is being requested for the
first area. Please explain.


>From Petra Barzin <barzin@xxxxxxxxxx>

[COMMENT 26]

I would propose the following:

- add one more sentence to section 6:

The protocol SHALL allow clients to obtain the identifier and
definition of a specific, the default or all of the policies supported
by the server by using another additional request/response pair.

[Answer 26]

Not all policies have a definition that can be given back (e.g. when locally
defined). However the identifier (e.g. OID) of the policy can always be
given back. So I would propose to change the sentence as follows:

"The protocol SHALL allow clients to obtain the references for a specific,
the default or all of the policies supported by the server by using an
additional request/response pair."

[COMMENT 27]

- and add another section after the PDP requirements:

Policy Retrieval Protocol (PRP) requirements
In order to archive the validation result of a certificate, it MAY be
necessary to combine it with the used validation policy. In some
cases the client MAY want to get an overview of all validation
policies supported by the server. Both reasons result in the following
requirements for the Policy Retrieval Protocol :

* return a specific validation policy definition
* return the default validation policy definition incl. its identifier
* return all validation policy definitions incl. their identifiers
* return max. number of validation policy definitions incl. their
identifiers
* return max. number of validation policy identifiers

The last two requirements are especially useful for thin clients with
small display facilities.

[Answer 27]

What you propose should be restricted to policies defined with the PDP
protocol. I would prefer to retrieve one by one the policies. So using first
the result of the previous responses, mandated by section 6, I would
propose the following text for a new section 9: 

Policy Retrieval Protocol (PRP) requirements

This protocol will allow to obtain the details of a policy provided that it
has been previously defined using PDP. Thus by providing an identifier, the
request will include the definition of the policy, as originally provided.

Regards,

Denis