Subject: SCVP Questions

From: "Seth Hitchings" <[email-masked]>
Date: Fri, 9 Jul 2004 13:21:18 -0400

I have a few questions about the way in which SCVP CVResponses to failed 
requests are constructed. I'm working with draft 14 of the spec.
 
First, assume that a request includes a bad check OID. Section 3.2.2 states that:
  "For each check, the SCVP server MUST perform all of the requested checks, or
   return an error."
In this case, I would expect the server to send back a ResponseStatus (section 4.4) 
of 27, unsupportedChecks. I find the term unsupported somewhat ambiguous, since
there is a difference between unsupported and unrecognized, but that's a
side issue. What I'm uncertain of is why the CertReply has a possible status 
of 1, unrecognizedCheck. If the check is unrecognized, the SCVP server is obliged
to return an error response per section 3.2.2, and therefore shouldn't be returning 
any CertReply.
 
I have the same issue with ReplyStatus 3, unrecognizedWantBack, since section 
3.2.3 states that:
  "For each type of information specified in the request, the server MUST return
   information regarding its finding (in a successful request)."
   
I have the same issue with ReplyStatus 7, unrecognizedExtension. First, I assume
this refers to queryExtensions? Section 3.2.18 states that
  "An SCVP server MUST rejeft the query if it encounters a critical extension
   it does not recognize..."
If the entire query is to be rejected, then why unrecognizedExtension a possible
ReplyStatus?
 
I have the same issue with ReplyStatus 8, unavailableValidityTime. Validity time
applies to all queriedCerts, so why indicate the error on a per ReplyStatus basis?
 
In general, it seems that errors that prevent the query from being processed
should be reported at the ResponseStatus level. In this case, no CertReply
objects would be expected in the response. Only those errors that are specific
to an individual query cert should be reported at the CertReply level.

Second, I find the use of ReplyWantBacks and ReplyChecks difficult in failure 
cases. Assume that a request asks for a certification path to be built for a single 
certificate. If no path can be built, the ReplyStatus is 10, certPathConstructFail,
and the ReplyChecks for the certification path building check is 1, "Could
not build a path". If a client sees the ReplyStatus, why would it bother checking
the CertReply? Additionally, the ReplyWantBack is required, but what value can I 
include? I couldn't build a CertPath.
 
The only case that I can see in which including ReplyChecks and ReplyWantBacks
in a CertReply with a non-success status makes sense is when the cert path
is not valid. In that case, the client may still want the cert path back, invalid
or not, especially when using untrusted SCVP.

Third, I'm unclear on exactly how keyUsage, extendedKeyUsage and isCA are used.
Must the SCVP server fail a check if the queried cert does not meet the criteria
of any of these parameters? If so, what is the expected ReplyStatus? Is it
validation failure, certPathNotValid? If so, are these parameters taken into
account only when building valid paths, and not when simply building an unvalidated
path?

Thanks,
Seth Hitchings