[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments to SCVP ID 17
Nathalie Jolly wrote:
1- Some general considerations
The abstract and introduction refer to a specification for
implementating DPD/DPV ("certificate path construction and validation"
as stated in the abstract), whereas the rest of the draft specifies
certificate validation as a whole (certificate content validation +
revocation status + building and validation of the certification
paths, depending of the chosen checks).
I would suggest :
- that you rewrite the abstract and introduction so that the purpose
of the document becomes clearer (SCVP includes DPD/DPV but also deals
with certificate content and revocation)
- that you distinguish in the text the "DPD" and the "DPV" part.
I do not understand. Certificate content validation and revocation
status checking are part of certification path validation.
Where specifically in the text is there a need to distinguish between
the DPD part and the DPV part? Remember that SCVP is simply one
protocol that can be used for both purposes.
2- Validation policies, checks and validation algorithms
2.1- The concepts
If I understand correctly :
- checks = the validations that the client wants done,
- validation policy = the values that the client wants the server to use
while performing the checks,
- validation algorithm = the algorithm to be used by the server for
performing the checks.
The server uses the "validation algorithm" in order to perform the
"checks" using the values of the "validation policy".
My feeling is that we need to define a name for (checks + validation
policy + validation algorithm). They are thinly correlated with
one another. In my opinion, the term "validation policy" should refer as
the whole (checks + validation policy + validation algorithm), since the
word "policy" means a global strategy more than just a few numerical
values.
Especially the algorithm should be a part of the "validation policy",
since each algorithm is an implementation of a set of checks. We could
have an algorithm per check and combine algorithms for each checks
combination.
Then, the chapters 5 and 6 (Server Policy request and response) would
send to the client the validation policies available, including checks
and algorithms for each response, and not two separate lists for
validation policies and validation algorithms.
I read that reviewers Wen-Cheng Wang and Denis Pinkas are of this
opinion, at least for merging "validation policy" and "validation
algorithm" (maybe not for the "checks"), and I totally agree with them.
The validation algorithm is already part of the validation policy. As
with other aspects of a validation policy, the validation policy defines
a default value and may or may not allow the client to request the use
of a non-default value.
As for combining the checks with the validation policy, this seems like
a rather significant change at the last minute and it does not seem that
the change is necessary nor have others requested such a change, so I
have to assume that the working group is generally in favor of the
current structure.
2.2- Checks, some complementary remarks
- §1 : Sentence "A server may choose to perform additional checks,
although the server cannot indicate in the response that the additional
checks have been performed." ->
What happens if an error occurs for one of these additional checks ? The
server should be able to send back an error message, which is not
possible if he cannot indicate the additional check in the response. Or
the client will not understand why the server returns an error.
This is an issue that Sharon Boeyen raised as well. If I understand
correctly, she would like to have the option of returning additional
checks items in the replyChecks field if additional checks were
performed and one of those additional checks resulted in an error. The
replyChecks would still be required to include all of the checks item
from the request, but would be allowed to include additional checks as
well. We will have to raise this issue at the meeting next week to see
if the working group favors such a change.
- The text does not address the possibility of keeping the calculated
paths (DPD) in a cache on the server between validation queries (DPV).
Certification paths should be able to be stored by the SCVP server and
not calculated for each request, since they do not depend on the
incoming certificate (2 certificates delivered by the same CA and been
validated under the same validation policy have the same certification
path at a given time). Thus, we need to state that the path building
is optional, if it has been done before and if the CA / validation
policy information have not been modified.
This is an implementation detail and not an aspect of the protocol. In
the protocol, it is clearly stated that cached responses may be allowed
except when the client insists on a non-cached response. I fully expect
servers to cache certification paths for use in responding to future
queries, but (other than when sending cached responses) the server's
doing so should have no affect on the client's query or the server's
response, just the efficiency with which the server generates the
response, so it outside the scope of the standard.
Therefore, we could have checks such as "id-stc-check-pkc-path" without
the "build" part.
The client can not include a certification path in its request (only a
set of certificates that the server may either use or ignore), so from
the client's point-of-view the server must always build a certification
path. Just because the client's request includes a check asking the
server to build a path does not mean that the server cannot simply
return a previously cached path as long as the returned path satisfies
the client's request.
More generally, the text should separate clearly what is the scope of
DPD and what is the scope of DPV.
SCVP already states which checks are required for DPD and which are
required for DPV. In draft 19, the text will state that only DPD
servers are required to implement id-stc-build-pkc-path and only DPV
servers are required to implement id-stc-build-valid-pkc-path and
id-stc-build-status-checked-pkc-path.
2.3- Validation policies
- Concerning the default values that can be overridden : a
simplification would be that the server does not return an error but
behaves as it should :
We could add an attribute : are_default_values_overridable
then the server behavior could be :
If (is_default_values_overridable) then :
- conflicts must not lead to server error
- and SCVP server takes new values
If !(is_default_values_overridable) then :
- conflicts must not lead to server error
- and SCVP server takes default values
It is my understanding that this is not the general view of the working
group. There seems to be consensus that the server must either use the
values specified by the client or return an error. If the server
indicates that a certificate is valid, but validated the certificate
using different input values than those requested by the client, then
the client may unknowingly accept a certificate that does not meet its
requirements.
- Concerning validation policy parameters :
The parameter list should be extensible. For example, we could make use
of a parameter stating if the certificate to validate must be a CA
certificate, a Enduser certificate or any type of certificate, ...
The parameters list is extensible. If the validation is performed using
a validation algorithm that accepts additional parameters, then those
additional parameters may be specified along with the algorithm. The
name validation algorithm, for example, includes additional parameters.
At one point there was a field that allowed the client to specify that
the certificate to be validated must be a CA certificate or an end
entity certificate. However, such a feature would have added
substantial complexity, so the decision was made to remove it from the
base standard with the understanding that this feature could always be
added in the future (e.g., as a new validation algorithm, a new check
item, an extension, etc.).
2.4- Client versus server authority
The text addresses the case where the client does not trust the server
and has to receive all the information used by the server, even if the
server validates the certification path, in order to be able to decide
not to trust the answer and query again the same or another server.
In organisations that want to centralize their PKI policies, the
projects that need a SCVP server cannot have the choice to contest the
authoritative answer of the SCVP server. Checks and validation policies
are contractually defined between the client and the server and the
client has to accept the answer received. In this context, we need a
protocol that gives the server the right to refuse subsequent requests
(which means : "SCVP servers MAY support serverContextInfo" - instead of
"SHOULD")
In most cases, I would expect serverContextInfo to be used for DPD,
where the certification path returned to the client may not satisfy the
client's validation policy requirements. The server may not validate
the path it is returning to the client, but may know about more than one
potentially acceptable certification paths. If the first path does not
meet the client's requirements and the server indicates that additional
paths are available, this provides a method for the client to request
another path.
serverContextInfo is less likely to be needed for DPV since the server
is validating that it has found a certification path that satisfies the
validation policy specified by the client. But, I do not see a
compelling reason to change "SHOULD" to "MAY". "SHOULD" does not mean
that a server that does not implement this is non-conformant. Also,
this "SHOULD" is referring to the implementation of the SCVP server
(i.e., the code). It says nothing about how a given SCVP server is
configured, which is the issue that you are concerned about.
3- serverContextInfo
I can't really understand the choice to implement this
"serverContextInfo" instead of letting the server send all the paths at
once. It means we have to keep context on the server for each query
(with all the subsequent questions : how long do we keep it ? do we need
to backup it for replay/verification purpose ?)
There is an id-swb-pkc-all-cert-paths wantBack, but this may not be the
best option depending on how the server is implemented. In many cases
the first path returned by the server will be acceptable to the client.
If the server had to return all paths, this would require extra
bandwidth and may require extra processing to compute the paths.
The subsequent questions are implementation details. It could be that
the server will retain information about previous queries for which it
returned a serverContextInfo, where the serverContextInfo could be an
index into this store. In this case, the server may store information
about a limited number of previous queries while deleting information
about old queries. Alternatively, the server may return all the
information needed in serverContextInfo so that it does not need to
remember anything about previous queries.
The text states that this value is used by the client if if finds the
response "unacceptable". What does "unacceptable mean" ? If it is
possible to define these "unacceptability criteria", they could be
implemented in the validation policy on the server, so that the server
gives the correct response at first query.
As I said above, I believe this feature will mostly be used with DPD.
In this case, the server may return certification paths without
validating them first, so the server would not know whether the path it
is returning satisfies the client's validation policy or not.
4- basic validation algorithm errors (3.2.4.2.2)
IIRC, the validation algorithm defined in section 6 of [PKIX-1] does not
contain any keyusage / revocation check. Thus, the
id-bvae-invalid-key-usage and id-bvae-revoked values are not used.
The validation policy includes keyUsages, which specifies requirements
if any for the end (or target) certificate. If the certificate includes
a keyUsage extension that does not satisfy the keyUsages requirement in
the validation policy, then the id-bvae-invalid-key-usage is returned.
Revocation checking must be performed by the server if the client
includes a check item that requires it. Also, section 6 of RFC 3280
does include revocation checking:
6.1.3 Basic Certificate Processing
The basic path processing actions to be performed for certificate i
(for all i in [1..n]) are listed below.
(a) Verify the basic certificate information. The certificate
MUST satisfy each of the following:
(3) At the current time, the certificate is not revoked and is
not on hold status. This may be determined by obtaining the
appropriate CRL (section 6.3), status information, or by out-
of-band mechanisms.
5- ValidationTime
I am afraid I missed the "clock skew" concept. IIUC, the idea of
introducing clock skew aims to solve the delay between the moment
where the user revokes his certificats and the moment where the system
is aware that the certificate is indeed revoked.
How does the SCVP server behave with the "clock stew" concept ?
- If the server builds a response concerning the state the
certificate was in 10 mn before the query, it increases the risk that
a certificate has been revoked in the meantime and that the SVCP
server is not yet aware of the revocation.
- If the server builds a response concerning the state the
certificate will be in 10 mn after the query, the server has to wait
10 mn before checking the certificate and sending the response to the
client.
The server would never have to wait before sending the response.
Section 3.2.7 states "A server can ignore the validationTime provided in
the request if the time is within the clock skew of the server's current
time." So, if the specified validationTime is the current time or less
than 10 minutes in the past (assuming the default value), the server can
just respond with the status at the current time. If the specified
validationTime is more than 10 minutes in the past, then validationTime
+ 10 minutes is already in the past so the server would be able to
respond immediately.
It seems to me that the solution is not clear enough in the text.
6- Some minor remarks
*** $3.2.2 : Sentence "For each check specified in the request, the
SCVP server MUST perform all of the requested checks, or return an
error".
please rewrite : "For each check specified in the request, the SCVP
server MUST perform the requested check, or return an error".
OK.
*** id-swb-pkc-best-cert-path : we lack a definition of what is the
"best" certification path and how the choice is made by the SCVP server.
This is just a name, not the description. Besides, the path returned by
the server is the one that it considers "best" given the specified
validation policy.
*** §3 Validation request
Please state that a SCVP server MUST process a protected request.
Section 4 states:
For protected requests and responses, SCVP servers MUST support
SignedData and SHOULD support AuthenticatedData. It is a matter of
local policy which types are used.
So processing protected requests is already required.
*** §3.2.7 validationTime
typo : valididationTime -> validationTime
OK.