Subject: Comments on SCVP draft 18

From: Sharon Boeyen <[email-masked]>
Date: Thu, 3 Mar 2005 16:05:12 -0500

I have reviewed the SCVP draft 18 spec and would first like to congratulate
and thank the authors for the vast improvement in readability, clarity and
specificity with this draft.
 
My technical concerns/comments follow.
 
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

Sharon Boeyen
Entrust Inc
[email-masked] <mailto:[email-masked]> 
www.entrust.com <http://www.entrust.com/>