[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments to SCVP ID 17
Hello,
I have been reading SCVP draft 17 in detail and I send you my reading
notes. I hope it will help you work on this topic. Since I began
reading, draft 18 has appeared but I kept working on draft 17. Sorry if
any of the following remarks have already been addressed.
Please keep in mind that I did not read the previous drafts and thus may
miss some of the design context. I am though quite familiar with
RFCs 2560 and 3280.
The following email deals first with my major remarks/questions on draft
17. I have also written down a non-exhaustive list of minor remarks,
which you will find at the end of this email.
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.
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.
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.
- 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.
Therefore, we could have checks such as "id-stc-check-pkc-path" without
the "build" part.
More generally, the text should separate clearly what is the scope of
DPD and what is the scope of DPV.
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
- 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, ...
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")
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 ?)
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.
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.
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.
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".
*** 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.
*** §3 Validation request
Please state that a SCVP server MUST process a protected request.
*** §3.2.7 validationTime
typo : valididationTime -> validationTime
I hope this contribution will help.
Sincerely yours,
Nathalie Jolly
Project manager for the development of a certificate validation service
for the french government.
--
Nathalie Jolly - inet6
-------------------------------------------------------------------
o Siege social: 51, rue de Verdun - 92 158 Suresnes
/ _ __ _ Bureaux: 33, rue Benoit Malon - 92150 Suresnes
/ /\ /_ / /_ France
\/ \/_ / /_/ Tel. +33 (0) 1 41 44 85 45
-------------- Fax +33 (0) 1 46 97 20 10
i n e t s y s http://www.inet6.fr