Comments on SCVP draft 18

1) In Section 3.2.2 I am pleased with the changes Tim stated in response to issue 6 of Denis' list where servers will no longer be mandated to support DPD as a minimum but can support DPV alone. My concern is with the ability of servers to perform additional checks beyond what the client requested but the requirement that the server not tell the client it performed those additional checks. This leads to a situation where, for example, a client that requested only path building may get a response from a server saying that no path could be built where in fact a path could have been built had that server NOT done the extra checks of revocation status and/or validation. The client is never told that this is the reason so they have no way to know whether or not to try another server (if they specifically wanted ONLY the requested checks performed) and they are misled into believing that no path can be built. If a server performs additional checks beyond what the client requested, and is providing a successful response to the client then I agree that there is no need for the server to inform the client about these additional checks. However, if the server is responding with an error and that error was due to the additional checks they performed, I believe that information must be returned to the client. At least the client would then have the information they need in order to determine whether an attempt to another server that doesn't perform those additional checks may result in a different response. I base this opinion on the belief that a client requests the type of checks they do for specific reasons. For example if a client requests DPV without revocation checking they've made that choice for some specific reason. Either they have revocation information already available and prefer to do the check themselves or they absolutely (for whatever reason) don't care about revocation status. If they did care and did want the check done by the server they would have asked for it. In these situations, if the server did the revocation checking anyway and found no valid path due to the fact that a certificate was revoked, the server should inform the client that did the checking and that was the reason for the failure.

2) In 1.5 various CRL schemes are mentioned, but partitioned CRLs are not. These should be added to the list.

3) In 3.2.4.2 the last paragraph mandates that both SCVP clients and servers support both the basic and the name validation algorithms. While I can understand the rationale for mandating this for servers, I don't understand why it is also mandated for clients. I think that should be left to implementers and/or profiles (e.g. a secure email client profile may certainly mandate client support for name validation for email addresses), but this shouldn't be mandated for all clients but left up to profiles to determine the mandatory/optional requirements for deployment scenarios/applications.

4) In 3.2.4.7 it states that servers must support trustAnchors. This is one that I think should not be mandated. In particular deployment scenarios the trust anchors may be mandated by local policy and the servers may only be permitted to use a specific set which are populated directly at the server. I think this should be changed to a "should" in the draft and leave it up to profiles to determine environments where it is mandated.

Cheers,

Sharon